[pdftex] pdfcreationdate format(s)

[Thierry Bouche]

Hi,

it seems there are two versions of \pdfcreationdate out there.

All those that I use output something in the form
D:20171205171912+01'00'
And that is what the manual describes

but I have trouble sharing code with some other installs where it
seems it can output something like
D:20171205162354Z

Does anyone know which versions of pdftex output the second version,
and how one can tell which one will be output (with a test, e.g.)?

Thanks,
Thierry

[Akira Kakuto]

Dear Thierry,

Post by Thierry Bouche
D:20171205171912+01'00'
D:20171205162354Z

I think the former is a local time, and the
latter is a universal time.

For example, if SOURCE_DATE_EPOCH is suitably defined, the
universal time is used.

I think that the variable SOURCE_DATE_EPOCH in
pdfTeX etc. is introduced in 2016.

Thanks,
Akira

[Thierry Bouche]

Hi,

Le mardi 5 décembre 2017 à 21:26:21, Akira Kakuto écrivit :

A> For example, if SOURCE_DATE_EPOCH is suitably defined, the
A> universal time is used.

Thanks, at last this made it possible for me to test things in both
cases and find a fix.

A> I think that the variable SOURCE_DATE_EPOCH in
A> pdfTeX etc. is introduced in 2016.

However I doubt this is set in a typical windows box, and the two
people so far that have had the Z version were using
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/W32TeX)
This is pdfTeX, Version 3.14159265-2.6-1.40.17 (MiKTeX 2.9.6210)

while I am using
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (MiKTeX 2.9.6400 64-bit)
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017)

and other people on various OSes never reported any problem.

Puzzling, isn't it?

Best,
Thierry

[Akira Kakuto]

Dear Thierry,

Post by Thierry Bouche
Puzzling, isn't it?

Sorry, as Karl said, 'Z' is used if
local time == UTC, even if SOURCE_DATE_EPOCH
is not defined.

Best,
Akira

[Karl Berry]

Hi Thierry,

D:20171205171912+01'00'
And that is what the manual describes

Seems I need to change the manual.

but I have trouble sharing code with some other installs where it
seems it can output something like
D:20171205162354Z

I'm not entirely sure, but the relevant code appears to be lines 3052.ff
of web2c/lib/texmfmp.c (in the function makepdftime):

if (off == 0) {
time_str[size++] = 'Z';
time_str[size] = 0;
} else {
off_hours = off / 60;
off_mins = abs(off - off_hours * 60);
i = snprintf(&time_str[size], 9, "%+03d'%02d'", off_hours, off_mins);
...

(where off is the computed timezone offset.)

svn blame tells me that Peter Breitenlohner was the last one to touch
these lines, in r30901, in 2013. Looking at that revision, I surmise
that the code existed before that (in pdftexdir/utils.c?) and he was
just moving things around at that time, but I didn't try to track it
back any further. I see nothing in any ChangeLog or NEWS files about it :(.

So the actual purpose of differentiating UTC like this, I cannot say
(maybe PDF wants it that way?), but it's apparently been around a long
time. I surmise the reason you are seeing it now is, as Akira said, the
SOURCE_DATE_EPOCH envvar feature added for reproducible build purposes,
which forces the utc interpretation.

So ... it seems to me that the only reliable approach is to be able to
handle either date format in whatever code is looking at the value. They
can't be differentiated by version, as the choice is made at runtime.

Best,
Karl