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

[Colin Watson]

On Tue, Dec 29, 2020 at 03:15:35PM +1100, G. Branden Robinson wrote:
> This issue is still open and tagged as a blocker for release, however.
> To resolve it we should settle on the time zone semantics of the system
> time retrieved by groff components (the formatter, the output drivers).
> We should also attempt to resolve these differing semantics between
> groff as distributed by GNU and by the Debian Project (and its many
> derivatives, none of which--to my knowledge--reverse the patch).
> 
> It appears to me that the consensus on this list is for groff to
> represent the system time in the local time zone, as date(1) does,
> whatever that may be.  People requiring reproducible builds should set
> TZ=UTC as well as SOURCE_EPOCH_DATE.

My apologies for dropping the ball on this thread.  I think I did a bad
job of communicating the problem.

Unfortunately, the solution above is not viable for Debian.  Harnesses
that test whether packages build reproducibly vary the TZ environment
variable intentionally (see
https://salsa.debian.org/reproducible-builds/reprotest/-/blob/master/reprotest/build.py),
as I understand it for good reasons: it's common for
inattentively-written build systems to have hidden dependencies on TZ
that affect things in surprising ways, and those harnesses are trying to
shake that sort of thing out.  They don't have a way to set TZ=UTC only
for groff.  I added this patch in Debian because the blast radius of
packages with reproducibility issues due to including groff output was
otherwise considerable, and it was by far the most economical way to
eliminate a class of reproducibility issues.

However, I made a strategic error in how I went about my previous
implementation.  My approach was just to use UTC unconditionally, since
I underestimated how much people would care about the current time
visible to groff programs.  Since it turns out that people do in fact
care, it seems to me that a better compromise would be to display the
time in UTC if the time was acquired from SOURCE_DATE_EPOCH, and
otherwise to display it in local time.  The broader user base who don't
care about reproducible builds won't be setting the SOURCE_DATE_EPOCH
environment variable anyway.  Anyone who is setting it is probably doing
so because they want to achieve some kind of reproducibility, and so is
rather more likely to be in the "systems programmer" camp; at the very
least, it ought to be easy for them to grasp why an invariant time zone
is useful in this context.

So, how about the attached patch?  I believe the results will not cause
the objections that were quite reasonably levelled at my previous
attempt, and it meets the reproducible-builds requirements that I know
about.

Thanks,

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]

0001-Display-time-from-SOURCE_DATE_EPOCH-in-UTC.patch
Description: Text Data