Re: FW: RFR: 8177276: MethodHandles.insertArguments doesn't specify IllegalArgumentException on index mismatch

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:

Re: RFR(s): 8171958: Several tests from java/time/test/java/time/format requiring jdk.localedata for execution

files. However this will lead to unnecessary test coverage reduction. -- Thanks and Regards, Nadeesh TV

Re: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

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

Re: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

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,

RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

and Regards, Nadeesh TV

Re: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

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

Re: RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale

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

Re: RFR 8160036: Java API doc for method minusMonths in LocalDateTime class needs correction

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

Re: RFR: JDK-8167618: DateTimeFormatter.format() uses exceptions for flow control.

167618/webrev.00/ <http://cr.openjdk.java.net/~rchamyal/anmeena/8167618/webrev.00/> -- Thanks and Regards, Nadeesh TV

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

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

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

) 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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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

Re: RFR:JDK-8160681:LocalDate.ofEpochDay input validation

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

RFR:JDK-8160681:LocalDate.ofEpochDay input validation

()* , *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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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&

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

: 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

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

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

RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

became too complex. Appreciate any suggestion to make the parsing less complicated -- Thanks and Regards, Nadeesh TV

Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

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

Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

-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

Re: RFR:JDK-8155823: Add date-time patterns 'v' and 'vvvv'

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

RFR:JDK-8155823: Add date-time patterns 'v' and 'vvvv'

://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

Add date-time patterns 'v' and 'vvvv'

of this. Special thanks for Stephen for his help in writing the spec. -- Thanks and Regards, Nadeesh TV

Add date-time patterns 'v' and 'vvvv'

of this. -- Thanks and Regards, Nadeesh TV

Re: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

, 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&

Re: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

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

Re: RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N'

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

Re: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

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

Re: RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N'

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:

Re: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

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

Re: RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N'

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

Re: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

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

RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

://cr.openjdk.java.net/~ntv/8079628/webrev.00/ <http://cr.openjdk.java.net/%7Entv/8079628/webrev.00/> -- Thanks and Regards, Nadeesh TV

RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N'

/ -- Thanks and Regards, Nadeesh TV

Re: RFR:JDK-8031085:DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

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

Re: RFR:JDK-8031085:DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

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

Re: RFR:JDK-8154050:java.time.format.DateTimeFormatter can't parse localized zone-offset

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

RFR:JDK-8031085:DateTimeFormatter won't parse dates with custom format "yyyyMMddHHmmssSSS"

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

Re: RFR:JDK-8154050:java.time.format.DateTimeFormatter can't parse localized zone-offset

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 &

Re: RFR:JDK-8148849:Truncating Duration

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

Re: RFR:JDK-8148947:DateTimeFormatter pattern letter 'g'

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

RFR:JDK-8148947:DateTimeFormatter pattern letter 'g'

of DateTimeFormatterBuilder as suggested by Stephen -- Thanks and Regards, Nadeesh TV

Re: RFR:JDK-8148849:Truncating Duration

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

RFR:JDK-8148849:Truncating Duration

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

RFR:JDK-8148950 :Enhance ChronoField Javadoc

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

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

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,

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

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

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

, 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

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

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

Re: RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")

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

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

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:/

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

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."

RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

v/8030864/webrev.01> -- Thanks and Regards, Nadeesh TV

Re: RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")

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

Re: RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")

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

RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")

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

Re: RFR:JDK-8146747:java.time.Duration.toNanos() and toMillis() exception on negative durations

) 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

Re: RFR:JDK-8146747:java.time.Duration.toNanos() and toMillis() exception on negative durations

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

RFR:JDK-8146747:java.time.Duration.toNanos() and toMillis() exception on negative durations

et/%7Entv/8146747/webrev.00/> -- Thanks and Regards, Nadeesh TV

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

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

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

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

RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

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

Re: RFR: JDK-8068803:Performance of LocalDate.plusDays could be better

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

Re: RFR: JDK-8068803:Performance of LocalDate.plusDays could be better

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

Re: RFR: JDK-8068803:Performance of LocalDate.plusDays could be better

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

RFR:8146489:@since tag missed

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

RFR: JDK-8068803:Performance of LocalDate.plusDays could be better

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

Re: RFR:8143413:add toEpochSecond methods for efficient access

, 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

RFR:JDK-8145166 : Duration.toString violates specification

- http://cr.openjdk.java.net/~ntv/8145166/webrev.00/ <http://cr.openjdk.java.net/%7Entv/8145166/webrev.00/> -- Thanks and Regards, Nadeesh TV

Re: RFR:8143413:add toEpochSecond methods for efficient access

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

Re: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration)

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

Re: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration)

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, "

RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration)

.java.net/%7Entv/8032510/webrev.02/> -- Thanks and Regards, Nadeesh TV

Re: RFR: JDK-8142936:Additional java.time.Duration methods

."; 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

Re: RFR: JDK-8142936:Additional java.time.Duration methods

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

RFR:JDK-8144349: @since tag missed

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

Re: RFR:JDK-8144349: @since tag missed

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

Re: RFR: JDK-8142936:Additional java.time.Duration methods

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

RFR:8143413:add toEpochSecond methods for efficient access

et/%7Entv/8143413/webrev.01/> -- Thanks and Regards, Nadeesh TV

RFR: JDK-8142936:Additional java.time.Duration methods

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

RFR:JDK-8071919 :Add java.time.Clock.tickMillis(ZoneId zone) method

.java.net/%7Entv/8071919/webrev.01/> -- Thanks and Regards, Nadeesh TV

RFR:JDK-8072746:LocalDate.isEra() should return IsoEra not Era

et/%7Entv/8072746/webrev.01> -- Thanks and Regards, Nadeesh TV

Re: RFR:JDK-8071919 :Add java.time.Clock.tickMillis(ZoneId zone) method

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

Re: RFR:JDK-8072746:LocalDate.isEra() should return IsoEra not Era

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.

RFR:JDK-8054978:java.time.Duration.parse() fails for negative duration with 0 seconds and nanos

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

Re: RFR:JDK-8133079:java.time LocalDate and LocalTime ofInstant() factory methods

: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/ --

RFR:JDK-8133079:java.time LocalDate and LocalTime ofInstant() factory methods

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

RFR:JDK-8138664- ZonedDateTime parse error for any date using 'GMT0' ZoneID

://cr.openjdk.java.net/~ntv/8138664/webrev.01 -- Thanks and Regards, Nadeesh TV

RFR:JDK-8066571:UnsupportedTemporalTypeException is thrown not only in the case of unsupported temporal

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

RFR:JDK-8138664- ZonedDateTime parse error for any date using 'GMT0' ZoneID

://cr.openjdk.java.net/~ntv/8138664/webrev.00/ -- Thanks and Regards, Nadeesh TV -- Thanks and Regards, Nadeesh TV

Re: RFR:8134928:java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970

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

RFR:8134928:java.time.Instant.truncatedTo(TemporalUnit unit) is truncating up if the year < 1970

rev.01/ -- Thanks and Regards, Nadeesh TV

JDK-8074023: Clock.system(ZoneId) could be optimized to always return the same clock for a given zone

/nadeesh-tv-8074023/ -- Thanks and Regards, Nadeesh TV Oracle IDC, 6th Floor Divyasree Chambers Mob: 9986800452

Code review request for JDK-8076441: Remove dead code in java.time.chrono.Chronology.isLeapYear

, Nadeesh TV