support reading extended timestamp information #160
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In an attempt to fix this: thejoshwolfe/yazl#70 , I learned how modern (circa 2008) zip file implementations encode timestamps in a not-terrible way. Let's add support to yauzl, then yazl.
This change will cause timestamps read by yauzl to be slightly more precise. If this throws off any unit tests that expect an exact value, you can either adjust the test or set
{forceDosFormat:true}
to restore the old behavior. I'm considering this to be a feature addition rather than a breaking change for semver purposes, because I believe the extra precision is generally an improvement and not a breaking change, but please open bug reports if you find a significant regression in the behavior.This change enables reading timestamps outside the range allowed by DOS, notably the UNIX epoch in 1970 is now possible, provided that the zip file creator used one of the supported extensions.