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

[Simon Josefsson]

Bruno Haible <bruno@clisp.org> writes:

> 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.

I agree.  Re-reading this documentation:

https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html

This suggests to me that the date to use is when the change was
installed/committed.  And since no time zone information is conveyed in
the file, I think the only reasonable way to write a local date/time is
to convert it to UTC0 (or some other non-tz dependent value) before
writing it to ChangeLog.  Anyone reading a changelog file couldn't
possibly know which time zone the committer was in.

That is not how C-x 4 a works, I believe it uses local time zone.  So I
think we will have to live with some inconsistency here.  It can also be
argued that the local date should be used: after all, if I'm committing
something on 2023-12-31 or 2024-01-01 locally, it shouldn't show up as
being done 2024-01-01 or 2023-12-31 which could even have legal
consequences.

> 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?

I'm fine with this -- and maybe while we are it, move a variant of the
gen-ChangeLog rule into maint.mk too?  Ideally it should be
automatically added to dist-hook when the gitlog-to-changelog gnulib
module is used, with some way to use a custom rule if the maint.mk
pre-provided one isn't sufficient.  Right now we duplicate this
Makefile.am snippet in way too many packages.  Then we can more easier
fix things like this by adding a --utc flag to the maint.mk instead of
requiring all maintainers to re-copy the Makefile.am snippet from the
gnulib manual.

/Simon

signature.asc
Description: PGP signature