[tex-k] [SPAM?] Reproducible builds using pdftex

[Norman Gray]

Jonathan, hello.

On 4 May 2016, at 13:21, Jonathan Kew wrote:

> In a context where SOURCE_DATE_EPOCH is used, "date" can easily 
> generate the numbers needed:
>
>     pdflatex `date -r ${SOURCE_DATE_EPOCH} "+\\year=%Y \\month=%m 
> \\day=%d"` \\input mydoc

Cunning, cunning...

> Overriding additional timestamps in metadata produced by pdftex, 
> dvips, dvipdfmx, etc is a different matter, but that's a distinct 
> issue that doesn't involve TeX primitives; it's about pdftex 
> extensions or separate driver programs.

If I'm following this thread correctly, then I think this latter point 
is the original motivation, and the question is whether or not this 
functionality should or should not be extended to so that the change of 
date also applies to the 'current date' as expressed in the \year, 
\month, \day and presumably \time primitives.

To be clear: I dispute the claim that defining SOURCE_DATE_EPOCH to 
change \today would constitute 'changes to the behavior of TeX 
primitives' (with its associated documentation burden).  The TeXBook 
doesn't specify what 'the current date' means, and while this of course 
has a natural meaning of 'now, according to the clock', the text is not 
inconsistent with an interpretation along the lines of 'now, according 
to the environment'.

It would be necessary to emphasise this behaviour in the documentation 
of SOURCE_DATE_EPOCH, but nowhere else.  Perhaps something like:

SOURCE_DATE_EPOCH=xxx : set the effective date for pdftex, as manifested 
in the values of CreationDate, ModDate, and others, in the PDF file.  
Note that this value also constitutes the 'current date' for TeX, and 
thus the derived values of the \year, \month, \day, and \time 
primitives, and the \today macro.

Best wishes,

Norman


-- 
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK