time: unable to parse UTC leap seconds

[aecolley]

What does 'go version' print?

go version go1.3.1 linux/amd64

What steps reproduce the problem?

Attempting to parse any valid leap second, such as "2005-12-31T23:59:60Z".
http://play.golang.org/p/lBYHT8mwbb

What happened?

parse error: parsing time "2005-12-31T23:59:60Z": second out of range

What should have happened instead?

parsed as: 2005-12-31T23:59:60Z

Please provide any additional information below.

http://golang.org/src/pkg/time/format.go has the immediate bug at lines 818-822:
  case stdSecond, stdZeroSecond:
    sec, value, err = getnum(value, std == stdZeroSecond)
    if sec < 0 || 60 <= sec {
      rangeErrString = "second"
    }

It seems that there's a fundamental restriction in the time package, where it repeats
the expensive POSIX mistake of assuming that you can ignore leap seconds if you're not
doing high-precision radio astronomy. Since leap seconds don't go away just because you
can't represent them in the most convenient time datatype, this makes the time package
useless for programs that are supposed to continue to run without crashing during a leap
second.

Suggested fixes:
1. Full support for conversion between monotonic counter (TAI) <=> wall time (UTC)
<=> POSIX time_t. The API is already flexible enough for this, but the
implementation would need to become aware of leap seconds.
2. Change the package documentation so it gives fair warning that "UTC"
doesn't mean real UTC, but has undefined behavior for leap seconds.
3. Abolish leap seconds. There may be politics involved.
4. Declare this behavior "working as intended". Make it someone else's problem
to cope with the next leap-second production crisis (scheduled for 2015). Deplore the
horrible hacks they perpetrate to keep the site up, eg:
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

[ianlancetaylor]

Comment 1:

Labels changed: added repo-main, release-none.

[rickb777]

Has this been kicked off into the long grass?

It's a shame it isn't getting some attention (especially in view of Java8 having finally sorted out the Java implementation https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html).

[PaluMacil]

This is somewhat related to Cloudflare's outtage this year: How and why the leap second affected Cloudflare DNS

[JohnSauter]

It would not be difficult to support leap seconds. See https://commons.wikimedia.org/wiki/File:Avoid_Using_POSIX_time_t_for_Telling_Time.pdf for some suggestions on how.

[mattjohnsonpint]

@PaluMacil - Not really. There was no parsing of ":60" involved in that particular problem.