Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UTC date in zip archive #361

Closed
wants to merge 1 commit into from
Closed

Conversation

jlaurens
Copy link
Contributor

@jlaurens jlaurens commented Jun 26, 2024

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

@josephwright
Copy link
Member

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.

@jlaurens jlaurens changed the title UTC date in tag target UTC date in tag target and zip archive Jun 26, 2024
@jlaurens
Copy link
Contributor Author

What is the link between the doc and the date?

@josephwright
Copy link
Member

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

@jlaurens
Copy link
Contributor Author

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 jlaurens changed the title UTC date in tag target and zip archive UTC date in zip archive Jun 27, 2024
Copy link
Member

@josephwright josephwright left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy with the doc change - but I'd like to see what Marcel thinks before moving forward, as the zip code is his.

Comment on lines -25 to +31
local concat = table.concat
local open = io.open
local osdate = os.date
local pack = string.pack
local concat = table.concat
local open = io.open
local os_date = os.date
local os_time = os.time
local pack = string.pack
local setmetatable = setmetatable
local iotype = io.type
local iotype = io.type
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really seeing the need for this but at the same time I have no strong objection

Comment on lines -36 to +37
local t = osdate('*t', unix)
local t = os_date('!*t', unix)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is a job of @zauguin

@jlaurens jlaurens closed this Jul 10, 2024
@zauguin
Copy link
Member

zauguin commented Jul 16, 2024

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.

@jlaurens
Copy link
Contributor Author

The libzip documentation is very clear on the subject.

@zauguin
Copy link
Member

zauguin commented Jul 16, 2024

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.

@jlaurens
Copy link
Contributor Author

Thanks for the clarification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants