Support parsing of leap second

[jodastephen]

Currently, any time with second-of-minute=60 can be successfully parsed, but will fail during the resolution phase when converting to LocalTime. To allow leap-second aware classes to parse the input, the conversion to LocalTime needs to be later, probably on-demand.

[jodastephen]

Unfortunately, leap seconds don't only happen at 23:59:60, they can happen at pretty much any local time (its always 23:59:60 UTC, but since the world has many offsets, including quarter hour ones, there is no clear way to determine if what is being parsed is a leap second or not. Options include

• always accept second-of-minute = 60
• only accept if minute = 14, 29, 44 or 59
• only accept if minute = 59 (bad for places with quarter hour/half hour zones)
• only accept 23:59:60 local time
• only accept 23:59:60 when using appendInstant(), where we know its UTC

I'm going with the last one of these at the moment as its less vulnerable to error.

[RogerRiggs]

Since the time model of 310 does not include leap seconds, why should they be supported? Just because of ISO? They will not be the result of any computation in 310, nor formatting and there is no mapping from the parse to a LocalTime, so what's the point?

[jodastephen]

External text strings will on occasion have leap seconds in. Most users will not test for this. While the support in the patch is not comprehensive, it is enough to handle the common case of parsing an instant, without getting into further behaviour.

As I've probably indicated before, I think it would be better for the JDK to have a file of leap-seconds, delivered as part of the time-zone data (as we used to have). Then parsing could be handled even better. But, this patch #297 provides the basic support.

[jodastephen]

Fixed by http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5c3984ba10a3