Simon Josefsson wrote: > > 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 ...
OK. > > > 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. OK, this means that instead of changing the example with TZ=UTC0 in the documentation, we should keep it and _add_ another example, with the new command-line option that does the "each commit its own time zone" logic. And let the maintainers pick the one they prefer. > 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. I think there's too much variation among GNU packages: - Some use a hand-written ChangeLog, some use gitlog-to-changelog. - Some have 1 ChangeLog, some have several ones (one per component). - Some use --no-cluster, some don't. - Some have a build-aux/git-log-fix file, some don't. - Some will want to use TZ=UTC0, some will prefer the "each commit its own time zone" logic. Bruno
