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
