RFR:JDK-8154050:java.time.format.DateTimeFormatter can't parse localized zone-offset
Stephen Colebourne
scolebourne at joda.org
Sun Apr 17 21:10:48 UTC 2016
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.
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
>
>
More information about the core-libs-dev
mailing list