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
