Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

+1 On 7/25/2016 7:43 AM, Stephen Colebourne wrote: I don't have any more comments, +1 Stephen On 25 July 2016 at 07:37, nadeesh tv wrote: Hi Stephen, Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8066806/webrev.11/ Changes: Included the suggestions

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

I don't have any more comments, +1 Stephen On 25 July 2016 at 07:37, nadeesh tv wrote: > Hi Stephen, > > Thanks for the comments. > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8066806/webrev.11/ > > Changes: Included the suggestions of Stephen > > Thanks and regards, > Nadees

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Stephen, Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8066806/webrev.11/ Changes: Included the suggestions of Stephen Thanks and regards, Nadeesh On 7/22/2016 3:38 PM, Stephen Colebourne wrote: These tests are expected to throw exceptions: tes

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

These tests are expected to throw exceptions: test_strict_appendOffsetId() test_strict_appendOffset_1() test_strict_appendOffset_2() test_strict_appendOffset_3() test_strict_appendOffset_4() As such, they should not contain assertEquals(). They should only contain the code that is expected to thr

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Roger, Thanks for the comments and sorry for the incorrect link. Please see the updated webrev which includes your suggestions. http://cr.openjdk.java.net/~ntv/8066806/webrev.10/ -- Thanks and Regards, Nadeesh TV On 7/21/2016 6:59 PM, Roger Riggs wrote: Hi Nadeesh, Found the changes in

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Nadeesh, Found the changes in http://cr.openjdk.java.net/~ntv/8066806/webrev.09/ Editorial: " Inthe lenient mode,*the *parser will be greedy and parse*the *maximum digits possible." TCKDateTimeFormatterBuilder.java: The lines 1473, 1479, 1485, etc. are way too long, perhaps wrap/break th

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8066806/webrev.08/ Changes in this webrev: For leninent mode , doc change in DateTimeFormatterBuilder.java " In the lenient mode, parser will be greedy and parse maximum digits possible. " Added new test cases for lenient mode

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

The test test_strict_offset_adjacentValidPattern_parse should also check that the hour of day was parsed to 12. I don't think there are any tests of the lenient behaviour? thanks Stephen On 10 June 2016 at 12:17, nadeesh tv wrote: > Hi, > > Please see the updated webrev > http://cr.openjdk.java

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8066806/webrev.08/ Thanks and Regards, Nadeesh On 6/9/2016 4:29 PM, nadeesh tv wrote: Hi Stephen, On 6/9/2016 4:19 PM, Stephen Colebourne wrote: "absHours / 10 > 0" would be simpler as "absHours >= 10" Around line 3595 we have

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot ...

Hi Paul, The blog entry specifically referred to the original java.util.Date API. JSR 310[1] (java.time) from its inception made the design choice to simplify the API and rely on operating systems to provide a stable and smooth time without leapseconds. The definition of the time scales used

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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"

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Stephen, On 6/9/2016 4:19 PM, Stephen Colebourne wrote: "absHours / 10 > 0" would be simpler as "absHours >= 10" Around line 3595 we have boolean paddedHour = isPaddedHour(); but 6 lines down isPaddedHour() is used, not the local variable There is an extra space in the message here: new

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

"absHours / 10 > 0" would be simpler as "absHours >= 10" Around line 3595 we have boolean paddedHour = isPaddedHour(); but 6 lines down isPaddedHour() is used, not the local variable There is an extra space in the message here: new DateTimeException(" Value out of Range also, I'd use "range", n

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Roger, Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8066806/webrev.07/ Thanks and regards, Nadeesh On 6/9/2016 2:36 AM, Roger Riggs wrote: HI Nadeesh, Looking better DateTimeFormatterBuilder: - line 3678: If array[1] == 24, offsetSeconds will b

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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" wrote: > Hi Paul, > > Java.time defines a day as exactly 86400 seconds; seconds are slightly > elastic as defined > by the clock source (usually th

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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 acr

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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 h

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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 o

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Stephen, Thanks for the suggestions and the code. 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 "Patterns containing "HH" will format and parse a t

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Where the new patterns are described in Javadoc, there is no discussion of the difference between "H" and "HH". Add after "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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi , On 5/27/2016 7:34 PM, Daniel Fuchs wrote: On 27/05/16 15:47, Roger Riggs wrote: Hi Nadeesh, Seeing the complexity of this code expand, I can't help wonder if there is a better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or two digits) with optional ":"s. And then match tha

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

On 27/05/16 15:47, Roger Riggs wrote: Hi Nadeesh, Seeing the complexity of this code expand, I can't help wonder if there is a better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or two digits) with optional ":"s. And then match that to the valid patterns. The use of numeric indi

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Nadeesh, Seeing the complexity of this code expand, I can't help wonder if there is a better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or two digits) with optional ":"s. And then match that to the valid patterns. The use of numeric indices obscures what is going on. Also,