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

[Roger Riggs]

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