-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
time: Sub doesn't respect leap seconds #15190
Comments
Related: #8728 In general, though, I don't think Go respects leap seconds and I wouldn't hold my breath on this getting fixed. Also, you've probably seen this before, but: https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html |
Thanks @bradfitz . I think an interim fix might be to make it clear on |
@phayes, that sounds reasonable. Can you file a separate bug just about that: Subject: "time: document that package does not support leap seconds" |
We've documented the calendar restriction, and we've fixed timing across leap seconds by using monotonic time. Including leap seconds in the civil calendar computations, however, would mean the computations change depending on how up to date the leap second info is, and a computation about the future would depend predicting the output of a future vote by the IERS. That is just not something to build a reliable system on. For this reason, Go's time package will not incorporate leap seconds into things like t.Sub of civil times. |
go version
)?go1.6 (playground)
go env
)?nacl (playground)
https://play.golang.org/p/qZ-RocY8nm
Output should be:
1s
2s
1s
1s
When calculating a Duration that crosses a leap second, go reports an incorrect duration. Note that in the playground example we are parsing UTC time and the UTC standard requires adherence to leap seconds.
This also means that the definition of the zero value of
time.Time
is incorrect.The documentation states: "The zero value of type Time is January 1, year 1, 00:00:00.000000000 UTC". This is incorrect.
The zero value of time.Time is actually
January 1, year 1, 00:00:26.000000000 UTC
The text was updated successfully, but these errors were encountered: