In an attempt to fix this: https://github.com/thejoshwolfe/yazl/issues/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.
In an attempt to fix this: https://github.com/thejoshwolfe/yazl/issues/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.