l3build icon indicating copy to clipboard operation
l3build copied to clipboard

UTC date in zip archive

Open jlaurens opened this issue 1 year ago • 4 comments

avoid local date in tagging. It assumes that the os.date is not buggy. Fix a bug in l3build-zip

jlaurens avatar Jun 26 '24 07:06 jlaurens

I'm not sure this makes sense: if the package date is ahead of the local date when you build docs, it could well fail.

josephwright avatar Jun 26 '24 08:06 josephwright

What is the link between the doc and the date?

jlaurens avatar Jun 26 '24 18:06 jlaurens

For example when l3doc checks that things are not deprecated ...

josephwright avatar Jun 26 '24 18:06 josephwright

Comparing times (or dates) in possibly different time zones gives undefined result, if you don't know the time zones in advance. l3doc silently assumes that the dates are in the local TZ, this should be documented in l3doc. New commit with changes replaced by documentation.

jlaurens avatar Jun 27 '24 06:06 jlaurens

Not sure why this is closed, but I don't have strong opinions on this. I'm weakly in favor of the change, but I'm guessing we should ask CTAN what they usually assume the times to mean in uploads.

zauguin avatar Jul 16 '24 05:07 zauguin

The libzip documentation is very clear on the subject.

jlaurens avatar Jul 16 '24 17:07 jlaurens

The libzip documentation is very clear on the subject.

The libzip file you linked only documents extra fields. I'm guessing you are referring to the UT (extra timestamp) extra field which in fact uses UTC based timestamps and which we generate. These timestamps are already correctly UTC encoded.

The function you propose to change is for the legacy timestamps. Their specification in APPNOTE says:

The date and time are encoded in standard MS-DOS format. If input came from standard input, the date and time are those at which compression was started for this data. If encrypting the central directory and general purpose bit flag 13 is set indicating masking, the value stored in the Local Header will be zero. MS-DOS time format is different from more commonly used computer time formats such as UTC. For example, MS-DOS uses year values relative to 1980 and 2 second precision.

I wouldn't refer to UTC as a "time format" but in any case it explicitly does not specify UTC for these. Also MS-DOS times are traditionally in the local timezone. Since you referenced libzip, libzip uses the local timezone for these.

zauguin avatar Jul 16 '24 19:07 zauguin

Thanks for the clarification.

jlaurens avatar Jul 17 '24 05:07 jlaurens