At 2020-12-16T10:54:40+0000, Colin Watson wrote: > On Wed, Dec 16, 2020 at 11:35:12AM +1100, G. Branden Robinson wrote: > > What do people think about a GROFF_USE_UTC environment variable that > > causes troff to call gmtime() instead of localtime()? > > How would this differ from just setting TZ=UTC?
It wouldn't, and your patch[1] is superior in every respect except for the disputed desirability of making groff ignore local time completely. > Also, this conversation seems to overlap substantially with > https://savannah.gnu.org/bugs/?57218, In comment #3 to that bug, I proposed that "groff 1.23 runs on UTC henceforth, even in compatibility mode." I would like now to retract that. Jim Avera make the point that he expects the same semantics from system time queries from groff(1) as he gets from date(1). I find that persuasive; not all groff users live or die by the status color of a continuous integration framework as some software engineers do. > so I thought I'd remind people of the existence of that report. Yes, thank you. That is clarifying. We need the Perl hash keys sorting fix and to deal with the injection of dates into generated files; the PostScript %%CreationDate comments are just one of a few examples. As your patch shows, the system time is fetched by several groff components; a better design probably would have been to embed the Unix epoch time (already retrieved by src/roff/troff/input.cpp) into the device-independent format and have the output drivers do with it what they will. As it is, you can have one date embedded in the document and disclosed via *roff registers, and a different one disclosed by the output driver. To resolve #57218 and this damnable time zone issue, I propose the following. 1. Integrate your Perl hash keys sorting fix. No one objects to it and it cuts out a lot of diff noise all by itself. I have this pending along with some other changes and will probably push today. 2. Switch output of date comments embedded by output drivers off by default, and add a common option to reënable them. Document this in NEWS. 3a. Add a device-independent output command, something like "x timestamp", which records the time gathered by input.cpp. 3b. Modify the HTML, PDF, and PostScript output drivers to initialize their idea of the current time from this new command instead of calling libgroff's `current_time()` themselves. 3c. At that point the only call site of `current_time()` will be input.cpp. Maybe the function should be moved out of the library. I guess 3a is arguably a NEWS item as well. I can imagine an argument for letting the output drivers continue to gather the system time for themselves, in that this could be used to measure the interval between formatter and output driver startup, but I find that dubious; the granularity is pretty coarse at one second and people would be better advised to undertake such performance measurements with greater resolution (and a large number of runs for statistical sanity). I still have a question, though: is the above enough for the Debian package? Is the combination of SOURCE_DATE_EPOCH and TZ=UTC going to make a reproducible groff build? Thoughts from anyone reading? Regards, Branden [1] https://salsa.debian.org/debian/groff/blob/master/debian/patches/display-utc-times.patch
signature.asc
Description: PGP signature
