Java is like many other systems, it uses a single count of seconds since a fixed epoch 1970-01-01 ignoring leap seconds (86400 second days). Such a representation cannot store a representation of a past leap second. But this thread is about offsets, which are completely unaffected by this! Stephen
On 8 June 2016 at 23:37, Paul Benedict <pbened...@apache.org> 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> >> 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/~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> 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 >>>>>> >>>>>> >>>> >>> >> >>
