Bruno Haible <br...@clisp.org> writes: > Hi Collin, > >> and then Paul added: >> >> > Emacs has had the tradition of using UTC for ChangeLog dates, so >> > please support that as well, as an option. > > and Simon did that, through documentation: In > <https://www.gnu.org/software/gnulib/manual/html_node/gitlog_002dto_002dchangelog.html> > he added the middle snippet with > > env LC_ALL=en_US.UTF-8 TZ=UTC=0 > > (Btw, is UTC=0 correct? I thought it should be UTC0, per > <https://lists.gnu.org/archive/html/bug-gnulib/2024-06/msg00214.html> ?)
This was based on some patches in Guix, but corrections welcome. >> I've attached a patch that I think deals with these issues. Can you all >> look over it for me? >> >> The patch adds a new '--utc' option and changes the default behavior so >> that localtime is no longer used. > > Both changes are bad. > > * To achieve the UTC display, Simon already showed how to do it: > Set the environment variable TZ to UTC0. If a feature can be achieved > by setting an environment variable, it's overkill to add a command-line > option that does the same thing. > > * 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. Thoughts? /Simon > - The dates come out unordered. See: > $ build-aux/gitlog-to-changelog --since=2024-01-01 | grep ^2024 > ... > 2024-06-29 Bruno Haible <br...@clisp.org> > 2024-06-28 Collin Funk <collin.fu...@gmail.com> > 2024-06-29 Bruno Haible <br...@clisp.org> > ... > 2024-06-26 Paul Eggert <egg...@cs.ucla.edu> > 2024-06-25 Collin Funk <collin.fu...@gmail.com> > 2024-06-26 Bruno Haible <br...@clisp.org> > ... > > Bruno > > > > >
signature.asc
Description: PGP signature
