groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PROPOSAL] time zones and reproducible builds (was: How to make grof


From: G. Branden Robinson
Subject: Re: [PROPOSAL] time zones and reproducible builds (was: How to make groff use local timezone?)
Date: Tue, 29 Dec 2020 15:15:35 +1100
User-agent: NeoMutt/20180716

I've made groff's build as reproducible as I can get it, as noted in the
comments to Savannah #57218[1].  The fix to pdfroff turned out to be
gentle and simple--just stop telling it to preserve temporary files
during the groff build.  That neatly reduced the size of a build diff by
99%.  What remains between successive builds using the same
SOURCE_DATE_EPOCH is less than 3 KiB of `diff -u` and easily eyeballed.

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.

If that is true, then our documentation of the several date/time (g)roff
registers should be reviewed to see where and how this fact should be
recorded.  Off the top of my head, I see this affecting our Texinfo
manual, groff(7), possibly groff_diff(7), and the man pages for the
output drivers that embed timestamp information (grohtml, grops,
gropdf).

Colin, what can groff do to make life easier for reproducible build
efforts in general and for this time zone issue in particular?

I will also note, since it's the perfect time of year to do so, that the
only component of a conventional date rendering (Y M D h m s) that
_isn't_ affected by time zone is the seconds field.  It will take 26
hours[2] for every time zone in the world to roll over to 1 January
2021, and some unfortunate millions of people live in places where the
time zone offset from UTC is a non-integral number of hours[3].

Regards,
Branden

[1] https://savannah.gnu.org/bugs/index.php?57218
[2] https://en.wikipedia.org/wiki/Line_Islands
[3] Doubtless some bureaucrat somewhere would innovate a sub-minute time
    zone offset if doing so would facilitate tracking the mobile devices
    of suspected dissidents.  Fortunately(?) this is not necessary; such
    tracking is already available upon request thanks to the heroic
    entrepreneurs of Silicon Valley.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]