+1
On 7/25/2016 7:43 AM, Stephen Colebourne wrote:
I don't have any more comments, +1
Stephen
On 25 July 2016 at 07:37, nadeesh tv wrote:
Hi Stephen,
Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8066806/webrev.11/
Changes:
I don't have any more comments, +1
Stephen
On 25 July 2016 at 07:37, nadeesh tv wrote:
> Hi Stephen,
>
> Thanks for the comments.
> Please see the updated webrev
> http://cr.openjdk.java.net/~ntv/8066806/webrev.11/
>
> Changes: Included the suggestions of Stephen
>
>
Hi Stephen,
Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8066806/webrev.11/
Changes: Included the suggestions of Stephen
Thanks and regards,
Nadeesh
On 7/22/2016 3:38 PM, Stephen Colebourne wrote:
These tests are expected to throw exceptions:
These tests are expected to throw exceptions:
test_strict_appendOffsetId()
test_strict_appendOffset_1()
test_strict_appendOffset_2()
test_strict_appendOffset_3()
test_strict_appendOffset_4()
As such, they should not contain assertEquals(). They should only
contain the code that is expected to
Hi Roger,
Thanks for the comments and sorry for the incorrect link.
Please see the updated webrev which includes your suggestions.
http://cr.openjdk.java.net/~ntv/8066806/webrev.10/
--
Thanks and Regards,
Nadeesh TV
On 7/21/2016 6:59 PM, Roger Riggs wrote:
Hi Nadeesh,
Found the changes in
Hi Nadeesh,
Found the changes in http://cr.openjdk.java.net/~ntv/8066806/webrev.09/
Editorial:
"
Inthe lenient mode,*the *parser will be greedy and parse*the *maximum digits
possible."
TCKDateTimeFormatterBuilder.java:
The lines 1473, 1479, 1485, etc. are way too long, perhaps wrap/break
Hi,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8066806/webrev.08/
Changes in this webrev:
For leninent mode , doc change in DateTimeFormatterBuilder.java
"
In the lenient mode, parser will be greedy and parse maximum digits possible.
"
Added new test cases for lenient
The test test_strict_offset_adjacentValidPattern_parse should also
check that the hour of day was parsed to 12.
I don't think there are any tests of the lenient behaviour?
thanks
Stephen
On 10 June 2016 at 12:17, nadeesh tv wrote:
> Hi,
>
> Please see the updated webrev
Hi,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8066806/webrev.08/
Thanks and Regards,
Nadeesh
On 6/9/2016 4:29 PM, nadeesh tv wrote:
Hi Stephen,
On 6/9/2016 4:19 PM, Stephen Colebourne wrote:
"absHours / 10 > 0" would be simpler as "absHours >= 10"
Around line 3595 we
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.
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"
Java is like many other systems, it uses a single count of seconds
since a fixed epoch 1970-01-01 ignoring leap seconds (86400 second
days). Such a representation cannot store a representation of a past
leap second.
But this thread is about offsets, which are completely unaffected by this!
Stephen
"absHours / 10 > 0" would be simpler as "absHours >= 10"
Around line 3595 we have
boolean paddedHour = isPaddedHour();
but 6 lines down isPaddedHour() is used, not the local variable
There is an extra space in the message here:
new DateTimeException(" Value out of Range
also, I'd use "range",
Hi Roger,
Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8066806/webrev.07/
Thanks and regards,
Nadeesh
On 6/9/2016 2:36 AM, Roger Riggs wrote:
HI Nadeesh,
Looking better
DateTimeFormatterBuilder:
- line 3678: If array[1] == 24, offsetSeconds will
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" wrote:
> Hi Paul,
>
> Java.time defines a day as exactly 86400 seconds; seconds are slightly
> elastic as defined
> by the
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
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
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
Hi,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/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
Hi Stephen,
Thanks for the suggestions and the code.
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
"Patterns containing "HH" will format and parse a
Where the new patterns are described in Javadoc, there is no
discussion of the difference between "H" and "HH".
Add after
"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
Hi ,
On 5/27/2016 7:34 PM, Daniel Fuchs wrote:
On 27/05/16 15:47, Roger Riggs wrote:
Hi Nadeesh,
Seeing the complexity of this code expand, I can't help wonder if there
is a
better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or
two digits) with optional ":"s.
And then match
On 27/05/16 15:47, Roger Riggs wrote:
Hi Nadeesh,
Seeing the complexity of this code expand, I can't help wonder if there
is a
better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or
two digits) with optional ":"s.
And then match that to the valid patterns.
The use of numeric
Hi Nadeesh,
Seeing the complexity of this code expand, I can't help wonder if there is a
better algorithm. Perhaps by trying to parse a 1 to 3 numbers(of 1 or
two digits) with optional ":"s.
And then match that to the valid patterns.
The use of numeric indices obscures what is going on.
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/
Solution: Added the suggested patterns but the parsing logic
25 matches
Mail list logo