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