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.ri...@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 > >
