Skip to content
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

Closed
phayes opened this issue Apr 8, 2016 · 4 comments
Closed

time: Sub doesn't respect leap seconds #15190

phayes opened this issue Apr 8, 2016 · 4 comments
Labels
FrozenDueToAge Thinking v2 An incompatible library change
Milestone

Comments

@phayes
Copy link

phayes commented Apr 8, 2016

  1. What version of Go are you using (go version)?
    go1.6 (playground)
  2. What operating system and processor architecture are you using (go env)?
    nacl (playground)
  3. What did you do?
    https://play.golang.org/p/qZ-RocY8nm
  4. What did you expect to see?
    Output should be:
    1s
    2s
  5. What did you see instead?
    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

@phayes phayes changed the title Duration incorrect when crossing UTC leap second Leap Seconds - Incorrect Duration, incorrect zero value of time.Time Apr 8, 2016
@phayes phayes changed the title Leap Seconds - Incorrect Duration, incorrect zero value of time.Time Leap Seconds - incorrect zero value of time.Time & incorrect Duration calculation Apr 8, 2016
@bradfitz bradfitz changed the title Leap Seconds - incorrect zero value of time.Time & incorrect Duration calculation time: Sub doesn't respect Leap Seconds Apr 8, 2016
@bradfitz bradfitz changed the title time: Sub doesn't respect Leap Seconds time: Sub doesn't respect leap seconds Apr 8, 2016
@bradfitz
Copy link
Contributor

bradfitz commented Apr 8, 2016

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

@bradfitz bradfitz added LongTerm Thinking v2 An incompatible library change labels Apr 8, 2016
@phayes
Copy link
Author

phayes commented Apr 8, 2016

Thanks @bradfitz . I think an interim fix might be to make it clear on time documentation that go doesn't use leap seconds at all. I had to spend a lot of time to figure out what the problem was, but a paragraph in the documentation explaining the lack of leap-second support and exactly what that means would go a long way.

@bradfitz
Copy link
Contributor

bradfitz commented Apr 8, 2016

@phayes, that sounds reasonable. Can you file a separate bug just about that:

Subject: "time: document that package does not support leap seconds"

@rsc
Copy link
Contributor

rsc commented Jun 16, 2017

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.

@rsc rsc closed this as completed Jun 16, 2017
@golang golang locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge Thinking v2 An incompatible library change
Projects
None yet
Development

No branches or pull requests

4 participants