Giters

golang / go

The Go programming language

Home Page:https://go.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

time: Sub doesn't respect leap seconds

phayes opened this issue · comments

commented
  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

commented

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

commented

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.

commented

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

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

commented

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.