You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The result of f.ModTime().Format("2006-01-02 15:04:05") has changed from Go 1.9 to Go 1.10. Given that ModTime is working with bit fields that encode yyyy/mm/dd hh:mm:ss, printing those fields should continue to reproduce their actual values (as Go 1.9 and earlier versions did).
The extra field beginning at offset 006d encodes the Unix time 0x386d4380 aka 2000-01-01 00:00:00 UTC. The MS-DOS time fields at offset 000c encode time=0x9800=19:00:00 date=0x279f=1999-12-31, aka what that Unix time displayed as in US Eastern time.
Here's a program that prints the zip.FileInfo's ModTime result:
$ go1.9 run r.go
1999-12-31 19:00:00 +0000 UTC
$ go run r.go
2000-01-01 00:00:00 +0000 UTC
$
This is clearly an improvement: the time instant is correct now and was incorrect in Go 1.9. However, it's also a regression, in that previously if you did t := f.ModTime() and then queried t.Year, t.Month, t.Day, t.Hour, t.Minute, t.Second, they all matched the encoded MS-DOS bits in the zip file. Now they don't.
Obviously the result of f.ModTime must change given the cleanup here. But in the Go 1.9 result the time zone was incorrect and the Year/Month/Day/Hour/Minute/Second was correct. I don't see why Go 1.10 is preserving the incorrect timezone and changing (breaking) the Year/Month/Day/Hour/Minute/Second. It seems like it should be preserving the correct Year/Month/Day/Hour/Minute/Second and changing (fixing) the time zone.
If you uncomment the Go 1.10-specific line in my program above, it prints:
$ go run r.go
2000-01-01 00:00:00 +0000 UTC
1999-12-31 19:00:00 -0500 -0500
$
It seems to me that ModTime() should simply return f.Modified directly, without the UTC coercion. That will effect the fix I suggested.
Then the original Go 1.9 vs Go 1.10 comparison becomes:
$ go1.9 run r.go
1999-12-31 19:00:00 +0000 UTC
$ go run r.go
1999-12-31 19:00:00 -0500 -0500
$
and that looks like a bug fix (instead of a bug being introduced).
An alternative would be to have ModTime continue to return the different time instant 1999-12-31 19:00:00 +0000 UTC. It's possible that that's an even better idea. One way or another though, the current output should change.
The result of f.ModTime().Format("2006-01-02 15:04:05") has changed from Go 1.9 to Go 1.10. Given that ModTime is working with bit fields that encode yyyy/mm/dd hh:mm:ss, printing those fields should continue to reproduce their actual values (as Go 1.9 and earlier versions did).
https://swtch.com/tmp/ziptime.zip is this file:
The extra field beginning at offset 006d encodes the Unix time 0x386d4380 aka 2000-01-01 00:00:00 UTC. The MS-DOS time fields at offset 000c encode time=0x9800=19:00:00 date=0x279f=1999-12-31, aka what that Unix time displayed as in US Eastern time.
Here's a program that prints the zip.FileInfo's ModTime result:
The output has changed since Go 1.9:
This is clearly an improvement: the time instant is correct now and was incorrect in Go 1.9. However, it's also a regression, in that previously if you did t := f.ModTime() and then queried t.Year, t.Month, t.Day, t.Hour, t.Minute, t.Second, they all matched the encoded MS-DOS bits in the zip file. Now they don't.
Obviously the result of f.ModTime must change given the cleanup here. But in the Go 1.9 result the time zone was incorrect and the Year/Month/Day/Hour/Minute/Second was correct. I don't see why Go 1.10 is preserving the incorrect timezone and changing (breaking) the Year/Month/Day/Hour/Minute/Second. It seems like it should be preserving the correct Year/Month/Day/Hour/Minute/Second and changing (fixing) the time zone.
If you uncomment the Go 1.10-specific line in my program above, it prints:
It seems to me that ModTime() should simply return f.Modified directly, without the UTC coercion. That will effect the fix I suggested.
Then the original Go 1.9 vs Go 1.10 comparison becomes:
and that looks like a bug fix (instead of a bug being introduced).
An alternative would be to have ModTime continue to return the different time instant
1999-12-31 19:00:00 +0000 UTC
. It's possible that that's an even better idea. One way or another though, the current output should change./cc @dsnet
The text was updated successfully, but these errors were encountered: