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
