Re: gitlog-to-changelog: Improve handling of time zones.

[Bruno Haible]

Hi Simon,

> >   * It drops the localtime() call, with two bad effects:
> >
> >       - The principle "Dates and times are always shown relative to the 
> > user's
> >         time zone, unless stated otherwise" is violated. This principle
> >         exists because most users don't want to deal with time zones. If you
> >         have a meeting with me at 15:00 GMT, it is *mandatory* that my
> >         calendar displays it to me as 17:00 - and your calendar as 08:00.
> >         "Unless stated otherwise" means, for example, "26 July 2024, 9:00
> >         Saipan time".
> 
> I agree with all that, HOWEVER the situation is different when the
> output is stored in a ChangeLog file that is included in tarballs and
> distributed to end users.  Then it is completely inappropriate to use
> localtime since that depends on the time zone of the release manager's
> laptop.
> 
> Isn't the problem because we have two different conflicting use-cases?
> 
> 1) running gitlog-to-changelog manually to get a human readable
> changelog file for easy reading.
> 
> 2) running gitlog-to-changelog during the release process to create a
> long-term archival copy of the changelog, which cannot assume anything
> about the reader's time zone and could then just as well either use UTC0
> or (maybe better) the local time zone of the original git commit?  For
> presentation purposes, I think it is nicer to print '2024-06-29' if the
> modification was committed on that day in the local time zone of
> whomever did the commit, even if that occured on 2024-06-28 or
> 2024-06-30 at UTC0.

Yes, listing the use-cases, like you do, is the only way forward here.

And I see that in April [1] I actually proposed the behaviour for 2),
that you agree to and that Collin implemented now.

Still, it troubles me (and I regret that I had not thought of it earlier)
that
  - A list of time points is presented, each occurring in a different
    time zone, but without the time zone.
  - As a consequence, the dates are not monotonically increasing.

But based on your use-cases list above, I don't see a better option for 2).

So, can we have
  - 1) with localtime(), as the default behaviour,
  - 2) as implemented by Collin, but enabled through a command-line option,
and then update the second example in the documentation [2], to remove
TZ=UTC=0 and use that command-line option instead?

         Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00192.html
[2] 
https://www.gnu.org/software/gnulib/manual/html_node/gitlog_002dto_002dchangelog.html