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

[Stephen Colebourne]

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 <pbenedict at 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.Riggs at 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.Riggs at 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.tv at 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
>>>>>>
>>>>>>
>>>>
>>>
>>
>>