Roger, what should I make of this announcement then? [1] A quote from it: "Although the Java API defines a second as a number between 0 and 61 to accommodate leap seconds, some applications may have taken short-cuts to assume that there are 60 seconds in a minute or 86400 seconds in a day. Systems that perform synchronized time-based transactions with other systems may run into issues if one system updates and another does not. The 2015 leap second takes place at exactly 23:59:60 UTC on June 30, 2015."
I am concerned that your change may break a long standing assumption. I am not totally convinced yet leap seconds are not supported -- or at least they have been implicitly supported. The latter has been my understanding and a communication like above makes me think it's more than an implicit support. Please advise. Thank you. [1] https://blogs.oracle.com/java-platform-group/entry/the_2015_leap_second_s Cheers, Paul On Thu, Jun 9, 2016 at 8:40 AM, Roger Riggs <roger.ri...@oracle.com> wrote: > Hi Paul, > > Right, java.time cannot represent time with that precision. > > Roger > > On 6/8/2016 6:37 PM, Paul Benedict wrote: > > So does that mean you can't use Java to represent a snapshot (instant) in > the past where a leap second existed? > On Jun 8, 2016 4:17 PM, "Roger Riggs" <roger.ri...@oracle.com> wrote: > >> Hi Paul, >> >> Java.time defines a day as exactly 86400 seconds; seconds are slightly >> elastic as defined >> by the clock source (usually the OS and the time servers). Having the >> time servers smoothly adjust >> the time around leap seconds has been a successful technique for robust >> application behavior >> across the OS and application time bases at the expense of some slight >> inaccuracy, some of which >> is unavoidable anyway without high precision sources. >> >> Roger >> >> >> >> On 6/8/2016 5:12 PM, Paul Benedict wrote: >> >> I might be wrong on this issue, but I think 24 could be valid -- but when >> (if ever) is the question. Google was the news for their 61 second minute >> [1] in their "leap minute" adventure. I am not sure how time corrections >> are always implemented, but if you can have a leap minute, couldn't you >> also have a leap hour? For example, wouldn't 24:00:00 be the equivalent of >> 23:59:60 under a different counting scheme? >> >> [1] >> http://www.businessinsider.com/google-compute-engine-leap-smear-deals-with-61-second-minutes-2015-6?r=UK&IR=T >> >> Cheers, >> Paul >> >> On Wed, Jun 8, 2016 at 4:06 PM, Roger Riggs < <roger.ri...@oracle.com> >> roger.ri...@oracle.com> wrote: >> >>> HI Nadeesh, >>> >>> Looking better >>> >>> DateTimeFormatterBuilder: >>> >>> - line 3678: If array[1] == 24, offsetSeconds will be greater that >>> seconds in a day; that's not right. >>> I don't think hour=24 is valid. (and there would be test case(s) for >>> it.) >>> >>> There should be test cases for offsets over the limit of hours, minutes, >>> and seconds: 24:60:60 >>> >>> Thanks, Roger >>> >>> >>> >>> On 6/8/2016 2:59 AM, nadeesh tv wrote: >>> >>>> Hi, >>>> >>>> Please see the updated webrev >>>> <http://cr.openjdk.java.net/%7Entv/8066806/webrev.06/> >>>> http://cr.openjdk.java.net/~ntv/8066806/webrev.06/ >>>> >>>> I reused code provided by Stephen and handled the edge cases accordingly >>>> >>>> Thanks and Regards, >>>> Nadeesh >>>> >>>> On 5/31/2016 7:15 PM, Stephen Colebourne wrote: >>>> >>>>> Where the new patterns are described in Javadoc, there is no >>>>> discussion of the difference between "H" and "HH". >>>>> >>>>> Add after </ul> >>>>> >>>>> "Patterns containing "HH" will format and parse a two digit hour, >>>>> zero-padded if necessary. Patterns containing "H" will format with no >>>>> zero-padding, and parse either one or two digits." >>>>> >>>>> "with colo" should be "with colon" >>>>> >>>>> As for the main code, I've had a go at a rewrite: >>>>> https://gist.github.com/jodastephen/68857dd344e33bd6c0b3b4d24279d2e4 >>>>> >>>>> It is completely untested, and surely has mistakes, however as a >>>>> design it seems reasonable. >>>>> >>>>> I agree that the tests need to cover these cases: >>>>> >>>>> - offset at end of line >>>>> - offset followed by letters >>>>> - offset followed by numbers >>>>> >>>>> Stephen >>>>> >>>>> >>>>> On 26 May 2016 at 08:49, nadeesh tv < <nadeesh...@oracle.com> >>>>> nadeesh...@oracle.com> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Please review >>>>>> >>>>>> BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 >>>>>> >>>>>> Issue: java.time.format.DateTimeFormatter cannot parse an offset with >>>>>> single >>>>>> digit hour >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ntv/8066806/webrev.03/ >>>>>> >>>>>> Solution: Added the suggested patterns but the parsing logic became >>>>>> too >>>>>> complex. >>>>>> Appreciate any suggestion to make the parsing less complicated >>>>>> >>>>>> -- >>>>>> Thanks and Regards, >>>>>> Nadeesh TV >>>>>> >>>>>> >>>> >>> >> >> >
