Hi Simon,
> I ran into a reproducability problem in gitlog-to-changelog, and noticed
> Guix people had also ran into this and worked around it outside of
> gitlog-to-changelog:
>
> https://issues.guix.gnu.org/70169/#21
>
> However I don't think it makes sense for ChangeLog dates to depend on
> the timezone under any circumstance.
>
> One nit may be that I'm not certain the 'git log' command is time zone
> dependent, but at least I could reproduce timezone problems before
> applying this patch but not after applying it, so I believe the 'git
> log' command already was not time zone dependent. Test like this:
>
> jas@kaka:~/src/gnulib$ build-aux/gitlog-to-changelog > foo
> jas@kaka:~/src/gnulib$ TZ=UTC0 build-aux/gitlog-to-changelog > bar
> jas@kaka:~/src/gnulib$ diff -ur foo bar
>
> I have committed this.
I don't agree with this patch. It misrepresents the dates on which people
have checked in their commits.
For example, assume a developer lives in California and makes many
commits after 17:00 local time. At some point he then makes a release.
If one of his commits was like this one from gnulib on 2024-03-16
(in 'git log --format=fuller' style):
commit af32ee824ee18255839f9812b8ed61aa5257a82b
Author: Paul Eggert <egg...@cs.ucla.edu>
AuthorDate: Sat Mar 16 22:27:48 2024 -0700
Commit: Paul Eggert <egg...@cs.ucla.edu>
CommitDate: Sat Mar 16 22:29:02 2024 -0700
renameatu: support RENAME_EXCHANGE on macOS
* lib/renameatu.c (renameat2ish, renameatu) [RENAME_SWAP]:
Use macOS RENAME_SWAP to implement GNU/Linux RENAME_EXCHANGE.
* tests/test-renameatu.c (main): Add a test for RENAME_EXCHANGE.
gitlog-to-changelog will now show it as:
2024-03-17 Paul Eggert <egg...@cs.ucla.edu>
renameatu: support RENAME_EXCHANGE on macOS
* lib/renameatu.c (renameat2ish, renameatu) [RENAME_SWAP]:
Use macOS RENAME_SWAP to implement GNU/Linux RENAME_EXCHANGE.
* tests/test-renameatu.c (main): Add a test for RENAME_EXCHANGE.
The ChangeLogs are not random data. They are text files meant to be read
and interpreted by humans. Shoving a "let's use GMT for everyone" attitude
here is not the right way to handle the diversity of time zones.
There was a problem already before, in gitlog-to-changelog. Namely, what
if a committer sits in California and the release manager, who creates the
tarball, sits in England or Germany? The same effect as above would occur.
But your change now made it even worse: Even the release manager cannot
override the time zone.
The real fix, IMO, is to use 'git log --format=fuller', and convert
the CommitDate (*) by removing the time zone. In the example above:
CommitDate: Sat Mar 16 22:29:02 2024 -0700
-> 2024-03-16
This way, each committer's days will be correctly represented.
Bruno
(*) CommitDate, not AuthorDate, because of the GNU Coding Standards. [1]
[1] https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
