[PROPOSAL] time zones and reproducible builds (was: How to make groff use local timezone?)

[G. Branden Robinson]

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