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

[Paul Benedict]

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