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 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.

@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.