Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
archive/zip: Writer should only use extended timestamps for non-zero times #17403
4c79ed5 caused a regression where a round-trip zip file does not preserve the same ModTime. The reason is because the logic for using extra timestamp is always applied in the Writer no matter what.
This is an issue for when the user doesn't set the ModifiedDate and ModifiedTime fields at all. Causing the Writer to convert a zero MS-DOS timestamp (gibberish) to a Unix timestamp (now gibberish) and back again. The fix is to only apply Extra timestamp only if the MS-DOS timestamp is non-zero.
This change reverts the following CLs: CL/18274: handle mtime in NTFS/UNIX/ExtendedTS extra fields CL/30811: only use Extended Timestamp on non-zero MS-DOS timestamps We are reverting support for extended timestamps since the support was not not complete. CL/18274 added full support for reading extended timestamp fields and minimal support for writing them. CL/18274 is incomplete because it made no changes to the FileHeader struct, so timezone information was lost when reading and/or writing. While CL/18274 was a step in the right direction, we should provide full support for high precision timestamps in both the reader and writer. This will probably require that we add a new field of type time.Time. The complete fix is too involved to add in the time remaining for Go 1.8 and will be completed in Go 1.9. Updates #10242 Updates #17403 Updates #18359 Fixes #18378 Change-Id: Icf6d028047f69379f7979a29bfcb319a02f4783e Reviewed-on: https://go-review.googlesource.com/34651 Run-TryBot: Joe Tsai <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Brad Fitzpatrick <email@example.com>