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

[nadeesh tv]

Hi Roger/Stephen,

On 4/18/2016 2:40 AM, Stephen Colebourne wrote:
> The LDML spec indicates that the "GMT" string should be localized:
> http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-dates.html#Using_Time_Zone_Names
> The text of appendLocalizedOffset() is written with the intention of
> the output being localized (otherwise, what is the point of the
> method!)
>
> I assume this was something that got missed when implementing
> appendLocalizedOffset(). It may require additional localized data from
> the LDML data files.
If OK, I will create a new enhancement request  for this in JBS

Regards,
Nadeesh
>
> This webrev looks fine.
> Stephen
>
>
>
> On 13 April 2016 at 16:56, Roger Riggs <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.
>>
>> 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.DateTimeFormatter can't parse localized zone-offset
>>
>> 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
>>
>>

-- 
Thanks and Regards,
Nadeesh TV