[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #57218] [PATCH] Reproducible builds support is broken and embeds ti
From: |
G. Branden Robinson |
Subject: |
[bug #57218] [PATCH] Reproducible builds support is broken and embeds timezone |
Date: |
Wed, 21 Oct 2020 04:05:26 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 |
Update of bug #57218 (project groff):
Severity: 3 - Normal => 5 - Blocker
Status: None => Need Info
_______________________________________________________
Follow-up Comment #2:
I nominate this as a blocker because the groff 1.23 release should be
reproducible.
> This patch should be incorporated upstream if possible. Was it ever proposed
here? Is it suitable for inclusion as-is?
No and no, not as far as I know. Colin Watson is active on the groff mailing
list (and has committed to its repository), so I reckon he'd have brought it
forward if he thought it was ready.
The tricky part would seem to be this:
> (Note that this changes the semantics of \n[hours] etc., so may need further
work.)
If anything the above is understated; it affects the semantics of every
date-related register coarser than the second, I reckon.
There are localtime offsets smaller than one hour; Australia perversely does
this, and as the great Christopher Hitchens pointed out:
"The time-zone difference between India and Pakistan, for example, is half an
hour. That's a nicely irrational and arbitrary slice out of daily life. In
Cyprus, the difference between the clocks in the Greek and Turkish sectors is
an hour--but it's the only in-country north-south time change that I am aware
of, and it operates on two sides of the same capital city."
The closer to New Year's Day you generate your document, the worse the
situation becomes.
That includes the traditional AT&T troff registers: \n[dw], \n[dm], \n[mo],
and \n[yr], plus the groff extensions \n[hours], \n[minutes], and \n[year].
(\n[yr] had a Y2K bug.)
I guess we could have a register \n[.utc] which is normally zero but is set to
1 if SOURCE_DATE_EPOCH is in the environment.
Thoughts?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?57218>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/