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.ri...@oracle.com
<mailto:roger.ri...@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.ri...@oracle.com
<mailto:roger.ri...@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.ri...@oracle.com <mailto:roger.ri...@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...@oracle.com
<mailto:nadeesh...@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
