Hi Vivek,
IMHO, assigning back to methodHandle onĀ line 109, 115, 122,123 is confusing
Regards,
Nadeesh
On 19/05/18 3:07 AM, Vivek Theeyarath wrote:
Hi All,
A gentle reminder seeking review.
Regards
Vivek
From: Vivek Theeyarath
Sent: Thursday, May 17, 2018 6:22 AM
To:
files. However this will lead to
unnecessary test coverage reduction.
--
Thanks and Regards,
Nadeesh TV
Hi Roger & Stephen,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8145633/webrev.13/
On 12/21/2016 3:11 AM, Roger Riggs wrote:
Hi Nadeesh,
On 12/20/2016 2:34 PM, nadeesh tv wrote:
Hi Roger & Stephen ,
Thanks for the comments.
Please see the updated webr
ucceed, because a single number is all that is needed to
parse day-of-week. (So, it will need to be removed from the invalid
patterns test).
Line 1869 will need to change to "count, count, count" to make the tests pass.
Otehrwise, looks fine, thanks.
Stephen
On 20 December 2016 at 09:55,
and Regards,
Nadeesh TV
ted code can still throw
DateTimeException from the call to getLong(). Unlike before, this
DateTimeException is desired.
Stephen
On 28 October 2016 at 16:58, nadeesh tv <nadeesh...@oracle.com
<mailto:nadeesh...@oracle.com>> wrote:
Hi Anubhav,
- * @throws DateTimeException if the fi
Bug id: https://bugs.openjdk.java.net/browse/JDK-8158880
Solution: To avoid test failure in non english locales, set the default locale while initial test setup
Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.00/
Thanks,
Bhanu
--
Thanks and Regards,
Nadeesh TV
for couple of methods in LocalDateTime and
OffsetDateTime classes
Webrev: http://cr.openjdk.java.net/~bgopularam/8160036/webrev.00
Thanks,
Bhanu
--
Thanks and Regards,
Nadeesh TV
167618/webrev.00/
<http://cr.openjdk.java.net/~rchamyal/anmeena/8167618/webrev.00/>
--
Thanks and Regards,
Nadeesh TV
Hi Ivan,
ZoneOffset.ofTotalSeconds(Integer.MIN_VALUE) have also the same issue. It' not
throwing the expected DTE.
May be you can correct this also as part of this.
Please update the copyright year also.
Rest looks good.
--
Thanks and Regards,
Nadeesh TV
On 8/18/2016 10:23 PM, Ivan
Hi ,
Sorry , my bad. I misread 'plusmn'.
--
Thanks and Regards,
Nadeesh TV
On 8/19/2016 11:10 AM, nadeesh tv wrote:
Hi Stephen/Ivan,
Is not the the statement
"Zone offset minutes and seconds must be negative because hours is
negative"
and the following doc definition contradic
) either).
test_strict_offset_adjacentInvalidPattern_parse
test_lenient_offset_adjacentInvalidPattern_parse
should not have .get(OFFSET_SECONDS)
Indentation on line 1621/1622
thanks
Stephen
On 22 July 2016 at 10:37, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi Roger,
Thanks for the co
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
or lenient mode.
--
Thanks and Regards,
Nadeesh TV
On 6/10/2016 4:47 PM, nadeesh tv wrote:
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 Colebo
r EpochDay.
Please see the updated webrev
http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.01/
Thanks and regards,
Nadeesh TV
Roger
On 7/1/2016 9:38 AM, Roger Riggs wrote:
Hi Stephen,
I'm a bit puzzled by the values recommended for the EpochDay Range.
The code should be
()* ,
*factory_ofEpochDay_belowMin()* .
Error was obscured. It was throwing *DateTimeException *because of
internally calculated YEAR was going out of range. Now it will throw
exception due to expected issue 'epoch day is out of range'.
--
Thanks and Regards,
Nadeesh TV
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&
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
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> wrote:
Hi all,
Please review
BugId : https://bugs.openjdk.java.net/browse/JDK-8066806
Issue: java.time.fo
:
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
Steph
Digit hour ( without
colons), it may cause confusion.
Thanks and Regards,
Nadeesh
best regards,
-- daniel
On 5/26/2016 3:49 AM, nadeesh tv wrote:
Hi all,
Please review
BugId : https://bugs.openjdk.java.net/browse/JDK-8066806
Issue: java.time.format.DateTimeFormatter cannot parse an offs
became too
complex.
Appreciate any suggestion to make the parsing less complicated
--
Thanks and Regards,
Nadeesh TV
Stephen
On 17 May 2016 at 05:18, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi Bhanu,
I think you should add a test case comparing the return value of
getFrom()
( Not an official reviewer)
Regards,
Nadeesh
On 5/16/2016 11:46 AM, Bhanu Gopularam wrote:
Hi all,
Could you please revi
-8156718
Solution: Added tck tests for validating getFrom method for unsupported non-Iso
temporal fields
Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/
Thanks,
Bhanu
--
Thanks and Regards,
Nadeesh TV
es or does not match
In the test it is a bit bothersome that the tests have to rely on
timezone specific data.
Thanks, Roger
On 5/9/2016 12:35 PM, nadeesh tv wrote:
Hi all,
Reposting because subject line did not follow the format.
Bug Id : https://bugs.openjdk.java.net/browse/JDK-8155823
Is
://bugs.openjdk.java.net/browse/JDK-8154567 as part of this.
Special thanks for Stephen for his help in writing the spec.
--
Thanks and Regards,
Nadeesh TV
of this.
Special thanks for Stephen for his help in writing the spec.
--
Thanks and Regards,
Nadeesh TV
of this.
--
Thanks and Regards,
Nadeesh TV
, SignStyle.NOT_NEGATIVE); Reviewed.
Roger
On 5/4/2016 3:15 AM, nadeesh tv wrote:
Hi,
Updated the webev http://cr.openjdk.java.net/~ntv/8079628/webrev.04/
Regards,
Nadeesh
On 5/3/2016 8:45 PM, Stephen Colebourne wrote:
Letters "Q", "q", "M", "L", "d", "D&
tion, but otherwise we stick with NORMAL for single
letter patterns like "D".
Stephen
On 3 May 2016 at 15:22, Roger Riggs <roger.ri...@oracle.com> wrote:
Hi Nadeesh,
On 5/3/2016 3:24 AM, nadeesh tv wrote:
Hi Roger,
Please see the answers inline
On 5/3/2016 2:43 AM, Roger Ri
negative. (Otherwise, there
should be test cases for negative values).
Thanks, Roger
On 4/28/2016 4:04 PM, nadeesh tv wrote:
Hi all,
Thanks Stephen for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8148949/webrev.02/
Regards,
Nadeesh
On 4/28/2016 7:58 PM, Stephe
unnecessary spaces
http://cr.openjdk.java.net/~ntv/8079628/webrev.03/
Regards,
Nadeesh TV
Thanks, Roger
On 4/28/2016 2:04 PM, nadeesh tv wrote:
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8079628/webrev.02/
Thanks and Regards,
Nadeesh TV
On 4/28/2016 8:17 PM
arguments from
data_secondsPattern)
Otherwise looks good.
Stephen
On 28 April 2016 at 14:12, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8148949/webrev.01/
Regards,
Nadeesh TV
On 4/25/2016 8:08 PM, nadeesh tv wrote:
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8079628/webrev.02/
Thanks and Regards,
Nadeesh TV
On 4/28/2016 8:17 PM, Stephen Colebourne wrote:
My mistake on the spec for "DD". It should be SignStyle.NOT_NEGATIVE,
not NORMAL.
I'd like to see a test t
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8148949/webrev.01/
Regards,
Nadeesh TV
On 4/25/2016 8:08 PM, nadeesh tv wrote:
HI all,
Please review a fix for
Bug ID - https://bugs.openjdk.java.net/browse/JDK-8148949
Issue - Pattern letters 'A' does not match
Hi all,
Thanks Stephen for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8079628/webrev.01/
Regards,
Nadeesh TV
On 4/26/2016 5:42 PM, Stephen Colebourne wrote:
This change introduces inconsistencies and problems. For example, it
will parse up to 19 digits
://cr.openjdk.java.net/~ntv/8079628/webrev.00/
<http://cr.openjdk.java.net/%7Entv/8079628/webrev.00/>
--
Thanks and Regards,
Nadeesh TV
/
--
Thanks and Regards,
Nadeesh TV
Hi Roger,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8031085/webrev.02/
Regards,
Nadeesh TV
On 4/19/2016 10:51 PM, Roger Riggs wrote:
Hi Nadeesh,
java/time/format/DateTimeFormatterBuilder.java:
- line 671, the @code should be @link, especially since it says
&quo
Hi Stephen,
Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8031085/webrev.01/
--
Thanks and Regards,
Nadeesh TV
On 4/18/2016 3:03 AM, Stephen Colebourne wrote:
The updated spec at line 670 is not clear - the adjacent parsing mode
only applies when
mment.
I'm not sure where the localized string for "GMT" would come from but it
might be a useful improvement
unless it was judged to a compatibility issue.
Roger
On 4/13/2016 10:19 AM, nadeesh tv wrote:
HI all,
Bug Id - https://bugs.openjdk.java.net/browse/JDK-8154050
Issue
of
NumberPrinterParser to make it participate in adjacent value parsing
2 existing test cases
TCKDateTimeFormatterBuilder.test_adjacent_lenient_fractionFollows_0digit
and test_adjacent_lenient_fractionFollows_2digit were failing. Changed
them accordingly.
--
Thanks and Regards,
Nadeesh TV
ight be a useful improvement
unless it was judged to a compatibility issue.
Could gmtText be made static final as it is declared in 3 or 4
methods if it is not being localized?
Roger
On 4/13/2016 10:19 AM, nadeesh tv wrote:
HI all,
Bug Id - https://bugs.openjdk.java.net/browse/JDK-8154050
&
Hi,
I need one more review for this change
Regards,
Nadeesh
On 3/30/2016 7:03 PM, Stephen Colebourne wrote:
Yes, that looks OK now.
thanks
Stephen
On 30 March 2016 at 12:25, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi Stephen,
Thanks for the comments.
Please see the updated webre
Gentle reminder
On 3/30/2016 11:41 PM, nadeesh tv wrote:
Hi all,
BUG ID : https://bugs.openjdk.java.net/browse/JDK-8148947
Webrev : http://cr.openjdk.java.net/~ntv/8148947/webrev.00/
Added new pattern letter 'g' for Modified Julian day.
Apart from that made clarification to JulianFields
of DateTimeFormatterBuilder as suggested by Stephen
--
Thanks and Regards,
Nadeesh TV
Hi Stephen,
Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8148849/webrev.01/
Made a change in unit == ChronoUnit.SECONDS also
Regards,
Nadeesh TV
On 3/29/2016 6:10 PM, Stephen Colebourne wrote:
We're almost there, but looking at the tests
Hi all,
Bug Id : https://bugs.openjdk.java.net/browse/JDK-8148849
Enhanced Duration by adding public Duration truncatedTo(TemporalUnit unit)
Please http://cr.openjdk.java.net/~ntv/8148849/webrev.00/
--
Thanks and Regards,
Nadeesh TV
Hi all,
Please see the doc changes
http://cr.openjdk.java.net/~ntv/8148950/webrev.00/
Bug ID https://bugs.openjdk.java.net/browse/JDK-8148950
--
Thanks and Regards,
Nadeesh TV
ould throw the expected
exception instead of epochSecond.
- test/java/time/tck/java/time/chrono/TCKIsoChronology.java
Since IsoChronology has completely different implementation,
test_epochSecond_bad() should
include out of range values for each or m,d,h,m,s.
Thanks, Roger
On 3/10/2016 4:53 AM,
and Regards,
Nadeesh TV
On 3/8/2016 4:14 AM, Roger Riggs wrote:
Look fine.
Roger
On 3/5/2016 7:05 AM, nadeesh tv wrote:
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.06/
Regards,
Nadeesh
On 3/4/2016 4:34 PM, Stephen Colebourne wrote:
long
, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi,
Roger - Thanks for the comments
Made the necessary changes in the spec
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.05/
On 3/3/2016 12:21 AM, nadeesh tv wrote:
Hi ,
Please see the updated webre
Hi,
Roger - Thanks for the comments
Made the necessary changes in the spec
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.05/
On 3/3/2016 12:21 AM, nadeesh tv wrote:
Hi ,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.03
ndZoneId();
"+01:Europe/London"
Note this special case, where the colon affects the parse type, but is
not ultimately part of the offset, thus it is left to match the
appendLiteral(":")
You may want to think of some additional nasty edge cases!
Stephen
On 25 February 201
y:
"to represent" -> remove as unnecessary in all places
These should be fixed to cleanup the specification.
The implementation and the tests look fine.
Thanks, Roger
On 3/2/2016 10:17 AM, nadeesh tv wrote:
Hi,
Stephen, Thanks for the comments.
Please see the updated webrev
http:/
Hi,
Stephen, Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.02/
Regards,
Nadeesh TV
On 3/2/2016 5:41 PM, Stephen Colebourne wrote:
Remove "Subclass can override the default implementation for a more
efficient implementation."
v/8030864/webrev.01>
--
Thanks and Regards,
Nadeesh TV
and seconds are optional.
* The colons are required if the specified pattern contains a colon.
* If the specified pattern is "+HH", the presence of colons is
determined by whether the character after the hour digits is a colon
or not.
* If the offset cannot be parsed then an exception is thrown unless
th
Gentle Reminder
On 2/12/2016 1:52 AM, nadeesh tv wrote:
Hi all,
Please review a fix for
Bug Id https://bugs.openjdk.java.net/browse/JDK-8032051
webrev http://cr.openjdk.java.net/~ntv/8032051/webrev.01/
--
Thanks and Regards,
Nadeesh TV
Hi all,
Please review a fix for
Bug Id https://bugs.openjdk.java.net/browse/JDK-8032051
webrev http://cr.openjdk.java.net/~ntv/8032051/webrev.01/
--
Thanks and Regards,
Nadeesh TV
)
2016-02-01 15:18 GMT+09:00 nadeesh tv <nadeesh...@oracle.com
<mailto:nadeesh...@oracle.com>>:
Hi all,
Please review following
Bug Id : https://bugs.openjdk.java.net/browse/JDK-8146747
<https://bugs.openjdk.java.net/browse/JDK-8146747>
Solution: Ha
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8146747/webrev.01/
Regards,
Nadeesh
On 2/3/2016 5:48 PM, nadeesh tv wrote:
Hi Shinya,
Thnx. I will update it.
Regards,
Nadeesh
On 2/3/2016 5:41 PM, ShinyaYoshida wrote:
Hi Nadeesh,
Almost LGTM!(But I'm not a reviewer
et/%7Entv/8146747/webrev.00/>
--
Thanks and Regards,
Nadeesh TV
Hi all,
Thanks for the suggestions.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8141452/webrev.01/
Regards,
Nadeesh TV
On 1/25/2016 10:24 PM, Roger Riggs wrote:
Hi Stephen, Nadeesh,
TimeUnit.toChronoUnit is a static method. It seems redundant to have
to pass an instance
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8141452/webrev.00/
--
Thanks and Regards,
Nadeesh TV
On 1/25/2016 9:01 PM, Stephen Colebourne wrote:
Typo "TimeUnitequivalent"
Otherwise looks good.
thanks
Stephen
On 25 January 2016 at 15:25, nadeesh t
Hi all,
Please review a fix for conversion between Chronounit and Timeunit
Bug ID : https://bugs.openjdk.java.net/browse/JDK-8141452
webrev: http://cr.openjdk.java.net/~ntv/8141452/webrev.00/
--
Thanks and Regards,
Nadeesh TV
by the checkValidValue()
Stephen
On 9 January 2016 at 09:33, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi Stephen/Roger,
Please see the updated the webrev
http://cr.openjdk.java.net/~ntv/8068803/webrev.03/
Explicit "YEAR.checkValidValue(year + 1);' added in 3rd case to handle the
invalidTooLarg
n new LocalDate(year, month, (int) dom);
(there are two occurrences)
Stephen
On 8 January 2016 at 10:56, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi all,
Thanks Stephen for the comments
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8068803/webrev.02/
Regards,
Nadeesh
On 1/7/2
necessary checks).
I'd like a few more test cases. Addition around 27/28/29/30 from the
first of Jan/Feb, and of 13/14/15/16 from the 15th of Jan and 15th of
Feb.
Stephen
On 7 January 2016 at 09:20, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi ,
Please see the updated webrev
http://cr.openjd
Hi all,
Please review a fix for
BugID - https://bugs.openjdk.java.net/browse/JDK-8146489
Issue - while fixing JDK8142936 , I forgot to add @since 9 tag.
webrev - http://cr.openjdk.java.net/~ntv/8146489/webrev.00/
--
Thanks and Regards,
Nadeesh TV
Hi all,
Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8068803
web rev : http://cr.openjdk.java.net/~ntv/8068803/webrev.00/
Special thanks for Stephen for providing the source code patch
--
Thanks and Regards,
Nadeesh TV
, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8143413/webrev.03/
Thanks and Regards,
Nadeesh
On 12/4/2015 3:56 AM, Stephen Colebourne wrote:
In the interests of harmony and getting something in, I'll accept that.
I
- http://cr.openjdk.java.net/~ntv/8145166/webrev.00/
<http://cr.openjdk.java.net/%7Entv/8145166/webrev.00/>
--
Thanks and Regards,
Nadeesh TV
On 11/30/2015 06:36 AM, Stephen Colebourne wrote:
The method Javadoc (specs) for each of the three new methods needs
to
be enhanced.
For the date ones it needs to say
"The resulting date will have a time component of midnight at the
start of the day."
For the time ones it needs to say
&q
return new Object[][] {
+ {new Duration.ofSeconds(0, 0), new Duration.ofSeconds(1, 0), 0},
etc.
Thanks, Roger
On 12/11/2015 7:14 AM, Stephen Colebourne wrote:
Fine by me.
Stephen
On 11 December 2015 at 11:53, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi all,
Please see the upd
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8032510/webrev.03/
Regards,
Nadeesh TV
On 12/11/2015 4:45 PM, Stephen Colebourne wrote:
Missing blank line after the new method.
Typo: "diviosr"
Replace:
Objects.requireNonNull(divisor, "
.java.net/%7Entv/8032510/webrev.02/>
--
Thanks and Regards,
Nadeesh TV
."; it should be omitted on
@return, @param
"+ * @return the number of milliseconds part of the duration."
Thanks for coalescing the data providers.
Roger
On 12/03/2015 12:52 PM, nadeesh tv wrote:
Hi all,
Please see the updated webrev -
http://cr.openjdk.java.net/~ntv/814
r each unit to reduce the duplication.
Thanks, Roger
On 11/30/2015 09:29 AM, Stephen Colebourne wrote:
I think thats ready to be merged, thanks
Stephen
On 30 November 2015 at 11:26, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi all,
Please see the updated webrev
http://cr.openjdk.j
Hi all,
Please review a fix for
BugID - https://bugs.openjdk.java.net/browse/JDK-814434
Issue - while fixing JDK-8071919, JDK-8133079 I forgot to add
@since 9 tag.
webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/
--
Thanks and Regards,
Nadeesh TV
Hi ,
Sorry. I made a mistake.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8144349/webrev.01
Regards,
Nadeesh
On 12/1/2015 10:24 PM, Stephen Colebourne wrote:
Those are not the right methods on LocalDate and LocalTime
Stephen
On 1 December 2015 at 16:50, nadeesh tv <nade
Hi all,
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8142936/webrev.02/
Regards,
Nadeesh TV
On 11/27/2015 11:20 PM, Stephen Colebourne wrote:
"Overall, looks pretty good.
There a a number of double spaces that should be single spaces in the Javadoc.
Change
"Thi
et/%7Entv/8143413/webrev.01/>
-- Thanks and Regards,
Nadeesh TV
rename privateBigDecimal toSeconds() ->private
BigDecimal toBigDecimalSeconds()
webrev - http://cr.openjdk.java.net/~ntv/8142936/webrev.01/
<http://cr.openjdk.java.net/%7Entv/8142936/webrev.01/>
--
Thanks and Regards,
Nadeesh TV
.java.net/%7Entv/8071919/webrev.01/>
--
Thanks and Regards,
Nadeesh TV
et/%7Entv/8072746/webrev.01>
--
Thanks and Regards,
Nadeesh TV
zero."
Though similar to the other methods, the "other than milli part" is
awkward.
With:
"This clock will always have the nano-of-second field truncated to
milliseconds"
The rest looks fine.
Thanks, Roger
On 11/13/2015 6:00 AM, nadeesh tv wrote:
Hi all,
Please r
Hi all,
Please review the updated webrev
http://cr.openjdk.java.net/~ntv/8072746/webrev.03/
Thanks and Regards,
Nadeesh TV
On 11/13/2015 8:40 PM, Roger Riggs wrote:
Hi Nadeesh,
The @return mentions "ISOChronoloy era constant" and it should
probably be a reference to IsoEra.
above , corrected a documentation error in the examples
for Duration.parse(CharSequence)
webrev - http://cr.openjdk.java.net/~ntv/8054978/webrev.02
<http://cr.openjdk.java.net/%7Entv/8054978/webrev.01/>
--
Thanks and Regards,
Nadeesh TV
:40, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi all,
Please review a fix for
Bug Id - https://bugs.openjdk.java.net/browse/JDK-8133079
Enhancement - Enhance LocalDate and LocalTime by adding .ofInstant(Instant,
ZoneId)
webrev - http://cr.openjdk.java.net/~ntv/8133079/webrev.01/
--
Hi all,
Please review a fix for
Bug Id - https://bugs.openjdk.java.net/browse/JDK-8133079
Enhancement - Enhance LocalDate and LocalTime by adding
.ofInstant(Instant, ZoneId)
webrev - http://cr.openjdk.java.net/~ntv/8133079/webrev.01/
--
Thanks and Regards,
Nadeesh TV
://cr.openjdk.java.net/~ntv/8138664/webrev.01
--
Thanks and Regards,
Nadeesh TV
an use
Apart from the above fix, corrected a documentaion error in IsoFields -
QUARTER_OF_YEAR
webrev - http://cr.openjdk.java.net/~ntv/8066571/webrev.04/
<http://cr.openjdk.java.net/%7Entv/8066571/webrev.04/>
--
Thanks and Regards,
Nadeesh TV
://cr.openjdk.java.net/~ntv/8138664/webrev.00/
--
Thanks and Regards,
Nadeesh TV
--
Thanks and Regards,
Nadeesh TV
is
needed. It needs one more test line for after 1970 and one for before
1970.
thanks
Stephen
On 14 October 2015 at 10:53, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi all,
Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8134928
Issue- java.time.Instant.trunc
rev.01/
--
Thanks and Regards,
Nadeesh TV
/nadeesh-tv-8074023/
--
Thanks and Regards,
Nadeesh TV
Oracle IDC, 6th Floor Divyasree Chambers
Mob: 9986800452
,
Nadeesh TV
98 matches
Mail list logo