RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot ...
Roger Riggs
Roger.Riggs at Oracle.com
Thu Jun 9 14:43:46 UTC 2016
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 in java.time are specified in
java.time.Instant [2].
Roger
[1] https://jcp.org/en/jsr/detail?id=310
[2] http://download.java.net/java/jdk9/docs/api/java/time/Instant.html
On 6/9/2016 10:31 AM, Paul Benedict wrote:
> 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 that perform synchronized time-based
> transactions with other systems may run into issues if one system
> updates and another does not. The 2015 leap second takes place at
> exactly 23:59:60 UTC on June 30, 2015."
>
> I am concerned that your change may break a long standing assumption.
> I am not totally convinced yet leap seconds are not supported -- or at
> least they have been implicitly supported. The latter has been my
> understanding and a communication like above makes me think it's more
> than an implicit support. Please advise. Thank you.
>
> [1]
> https://blogs.oracle.com/java-platform-group/entry/the_2015_leap_second_s
>
> Cheers,
> Paul
>
> On Thu, Jun 9, 2016 at 8:40 AM, Roger Riggs <Roger.Riggs at oracle.com
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
> 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
>>>
>>>
>>>
>>>
>>
>
>
More information about the core-libs-dev
mailing list