Follow-up Comment #16, bug #57218 (project groff):
[comment #14 comment #14:] > My Debian-based system is running groff 1.22.4. > > On the other hand, groff from Git HEAD and 1.22.4 do handle the time zone differently; this is easily demonstrated by generating a blank PostScript document. > > > $ echo | groff | grep '%%CreationDate' > %%CreationDate: Mon Dec 28 03:17:07 2020 > $ echo | ./build/test-groff | grep '%%CreationDate' > %%CreationDate: Mon Dec 28 14:17:10 2020 > $ echo | SOURCE_DATE_EPOCH=1609125163 groff | grep '%%CreationDate' > %%CreationDate: Mon Dec 28 03:12:43 2020 > $ echo | SOURCE_DATE_EPOCH=1609125163 ./build/test-groff | grep '%%CreationDate' > %%CreationDate: Mon Dec 28 14:12:43 2020 > > > So that's the next item for research. The above was the product of my repeated error of forgetting that Debian's groff is patched to return `gmtime()` instead of `localtime()`. So this issue now boils down to the one posed by Eli in the first place. Should groff implicitly incorporate the system's time zone into built artifacts? Consensus on the mailing list appears to have roughly converged on "yes", because it is easily overcome--anyone who sets SOURCE_DATE_EPOCH can with equal ease also set TZ=UTC, whereas going the other direction (inferring and reversing a time zone offset) is immensely more complicated. Comments? _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?57218> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/