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

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

quot; to all 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

s should succeed, 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

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

ial thanks to Stephen for the help. -- Thanks and Regards, Nadeesh TV

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

ateTimeException from the call to getLong(). Unlike before, this DateTimeException is desired. Stephen On 28 October 2016 at 16:58, nadeesh tv <mailto:nadeesh...@oracle.com>> wrote: Hi Anubhav, - * @throws DateTimeException if the field is not available and the section is not

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

wing issue 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

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,

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

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

offset in seconds, from 0 to ±59 -- Thanks and Regards, Nadeesh TV On 8/18/2016 11:46 PM, Stephen Colebourne wrote: Looks good Stephen On 18 August 2016 at 17:53, Ivan Gerasimov wrote: Hello everybody! The factory methods of ZoneOffset class demonstrate a minor inconsistency. Normall

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 wrote: Hi Roger, Thanks for the comments and sorry for the

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 in

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 com

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

.parse(offset + "12345") which should work for most of the patterns. I intentionally avoided it. I will create a positive test cases for working patterns and negative test cases for rest. Regards, Nadeesh thanks Stephen On 9 June 2016 at 10:27, nadeesh tv wrote: Hi Roger, Thanks for the commen

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

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

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

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 wrote: Hi all, Please review BugId : https://bugs.openjdk.java.net/browse/JDK-8066806 Issue: java.time.format.Dat

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 St

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

hose patterns for Single 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.DateTimeForma

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 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 review fix for following i

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'

can this be more specific about what matches 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 : h

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

related bug https://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'

4567 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'

567 as part 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

t option, but otherwise we stick with NORMAL for single letter patterns like "D". Stephen On 3 May 2016 at 15:22, Roger Riggs 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 Riggs wrote: Hi Nadeesh

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

uld 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, Stephen Colebourne wrote: I&#

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

d the webrev by removing some 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, Na

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

more arguments from data_secondsPattern) Otherwise looks good. Stephen On 28 April 2016 at 14:12, nadeesh tv 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 review a fi

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

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 for

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

MAL) Webrev - http://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'

.openjdk.java.net/~ntv/8148949/webrev.00/ -- 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 "see

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

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 - java.time.format.DateTimeF

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

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

rovement 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 <https://bugs.openjd

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

he new test cases file -- Thanks and Regards, Nadeesh TV

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 wrote: Hi Stephen, Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv

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 Ju

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

m docs 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 test

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

date would 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

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 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 webrev http://cr.openjdk.java.net/~ntv/8030864

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

Builder().parseLenient().appendOffset("HH:MM").appendZoneId(); "+01:00Europe/London" "+0100Europe/London" DateTimeFormatterBuilder().parseLenient().appendOffset("HH:MM").appendLiteral(":").appendZoneId(); "+01:Europe/London" Note this

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

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

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

inutes 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 t

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

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 rev

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

(Shinya Yoshida) 2016-02-01 15:18 GMT+09:00 nadeesh tv <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: Handled th

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 tv w

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

y the checkValidValue() Stephen On 9 January 2016 at 09:33, nadeesh tv 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 invalidTooLarge year cas

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

o return new LocalDate(year, month, (int) dom); (there are two occurrences) Stephen On 8 January 2016 at 10:56, nadeesh tv 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/2016 6:15 PM, Ste

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

of unnecessary 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 wrote: Hi , Please see the updated webrev http://cr.openjdk.java.net/~nt

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 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 think LocalDate.EPOCH is pro

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

of that day. It is strange to have the Local/OffsetTime to have two public methods with the assumption of the "date" is at epoch year/month/day. What's the use case/scenario for these two proposed methods? -Sherman On 11/30/2015 06:36 AM, Stephen Colebourne wrote: The method Java

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 wrote: Hi all, Please see the updated webrev http://cr.openjdk.jav

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

nal "."; 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/~

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

e 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 wrote: Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8142936/webrev.02/ Regards, Nadeesh TV On

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 wrote

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

RFR:8143413:add toEpochSecond methods for efficient access

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

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 "This i

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

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

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

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

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

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

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

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

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

:40, nadeesh tv 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/ -- Thanks and Regards, Nadeesh TV

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

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

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

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

nding 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 wrote: Hi all, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8134928 Issue- java.time.Instant.truncatedTo(TemporalUnit unit) is 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

  1   2   >