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

[Roger Riggs]

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" <Roger.Riggs at oracle.com 
> <mailto: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 <mailto: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/
>>             <http://cr.openjdk.java.net/%7Entv/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
>>                 <mailto: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/
>>                     <http://cr.openjdk.java.net/%7Entv/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
>>
>>
>>
>>
>