UTC date in zip archive
avoid local date in tagging.
It assumes that the os.date is not buggy.
Fix a bug in l3build-zip
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.
What is the link between the doc and the date?
For example when l3doc checks that things are not deprecated ...
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.
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.
The libzip documentation is very clear on the subject.
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.
Thanks for the clarification.