RFR:JDK-8154050:java.time.format.DateTimeFormatter can't parse localized zone-offset
Roger.Riggs at Oracle.com
Wed Apr 13 17:06:24 UTC 2016
Literal strings are interned by the compiler but it would make it
clearer that it is the same string
everywhere. Though I find it easier to read when the value is inline
without having to do the indirection to a constant.
And its really not going to change; "GMT" is too deeply embedded in the
On 4/13/2016 12:33 PM, Lance Andersen wrote:
>> On Apr 13, 2016, at 11:56 AM, Roger Riggs <Roger.Riggs at oracle.com
>> <mailto:Roger.Riggs at oracle.com>> wrote:
>> Hi Nadeesh,
>> The bugfix looks fine.
>> The TODO comment on the "GMT" raises the question (as a separate issue)
>> about implementing the TODO or removing the TODO comment.
>> 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.
> Could gmtText be made static final as it is declared in 3 or 4
> methods if it is not being localized?
>> 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.DateTimeFormatter can't parse localized
>>> Solution - Corrected the mistake in calculating parse end position
>>> and removed an unnecessary null check
>>> webrev - http://cr.openjdk.java.net/~ntv/8154050/webrev.00/
>>> PS: TCKOffsetPrinterParser.test_print_localized() already contain
>>> some test cases related to parsing and formatting. therefore did not
>>> repeat in the new test cases file
>>> Thanks and Regards,
>>> Nadeesh TV
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
More information about the core-libs-dev