Bruno Haible <br...@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
