RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

2018-10-01 Thread Pallavi Sonal
Thanks Roger, made the suggested changes.   Thanks, Pallavi Sonal   From: Roger Riggs Sent: Monday, October 01, 2018 9:29 PM To: Pallavi Sonal ; Naoto Sato ; core-libs-dev Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets   Hi, The checkbox

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

2018-10-01 Thread Pallavi Sonal
Hi Naoto, Here is the CSR for review : https://bugs.openjdk.java.net/browse/JDK-8211316 Thanks, Pallavi Sonal -Original Message- From: Naoto Sato Sent: Friday, September 28, 2018 9:38 PM To: Pallavi Sonal ; Roger Riggs ; core-libs-dev Subject: Re: RFR: JDK-8166138

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

2018-09-28 Thread Pallavi Sonal
Thanks Roger. I will update it before the commit. -Original Message- From: Roger Riggs Sent: Friday, September 28, 2018 6:15 PM To: Pallavi Sonal ; core-libs-dev Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets Hi Pallavi, Looks fine, But can you

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

2018-09-28 Thread Pallavi Sonal
Thanks Roger and Stephen. Here is the updated webrev with the suggested changes: http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/ Thanks, Pallavi Sonal -Original Message- From: Roger Riggs Sent: Friday, September 28, 2018 12:51 AM To: core-libs-dev Subject: Re: RFR: JDK-8166138

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

2018-09-26 Thread Pallavi Sonal
Thanks for the clarification. Here is the updated webrev for review : http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/ Thanks, Pallavi Sonal -Original Message- From: Stephen Colebourne Sent: Tuesday, September 25, 2018 4:39 PM To: core-libs-dev Subject: Re: RFR: JDK-8166138

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

2018-09-25 Thread Pallavi Sonal
as necessary. thanks Stephen On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal wrote: > > Thank you Stephen for your inputs. Based on that, here is the updated webrev > for review : > http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/ > > Thanks, > Pallavi Sonal. > > -O

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

2018-09-21 Thread Pallavi Sonal
Thank you Stephen for your inputs. Based on that, here is the updated webrev for review : http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/ Thanks, Pallavi Sonal. -Original Message- From: Stephen Colebourne Sent: Thursday, September 20, 2018 6:38 PM To: core-libs-dev Subject

RE: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

2018-09-20 Thread Pallavi Sonal
Thanks Roger , Naoto and Stephen for the review and valuable inputs. Here is the updated webrev for review : http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/ Thanks, Pallavi Sonal -Original Message- From: Stephen Colebourne Sent: Thursday, September 20, 2018 2:50 AM To: core

RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets

2018-09-19 Thread Pallavi Sonal
, "+", or "+00" will not be accepted in the input string to be parsed. [1] https://en.wikipedia.org/wiki/ISO_8601 Thanks, Pallavi Sonal

Re: RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding

2018-04-30 Thread Pallavi Sonal
d the adjacent value parsing only happens with another parser for the consecutive non-padded fields. Should the PadPrinterDecoratorParsers be allowed to participate in adjacent value parsing and should this affect both padded followed by non-padded fields as well as non-padded followed

RFR: JDK-8193877- DateTimeFormatterBuilder throws ClassCastException when using padding

2018-04-18 Thread Pallavi Sonal
tException is thrown. The fix has been done to check such cases where the previous parserprinter is PadPrinterDecoratorParser and use the new NumberPrinterParser instead for parsing the next value. All the tier1 and tier2 Mach 5 tests have passed. Thanks, Pallavi Sonal

RFR: JDK-8144300 : Java does not honor http.nonProxyHosts value having wildcard * both at end and start

2018-03-01 Thread Pallavi Sonal
of http.nonProxyHosts , the code works as expected and DIRECT connection is used for them. But in scenarios, where there is a wildcard both at the beginning and end of the hostname, proxy is used instead of DIRECT connection. All the tier1 and tier2 Mach 5 tests have passed. Thanks, Pallavi