[threeten-dev] Localized GMT offset

[Xueming Shen]

The difficulty here is that those prefixes are not part of the JSR310 offset "zone" name,
but regional zone name. And now we are talking about they are actually part of the
offset formats, when if "localized". This is one the reason I suggested, maybe, just
maybe those prefixes should be part of the offset "zone" names during the conf call.

Anyway to treat it as a single "localizedOffset" form might be an alternative, just
ignore above possible issue. But I don't think currently there is such "localization data"
clearly defined in JDK and exists in JDK/CLDR data. Maybed we can skip this one for
now and only add ZZZZZ for 8?

Sherman

On 03/22/2013 03:09 PM, Stephen Colebourne wrote:
> My interpretation of CLDR is that there is a single "localized offset"
> format. So I would expect that the new method on the formatter builder
> would be appendLocalizedOffset() where the format is derived entirely
> from localization data (gmtOffset, gmtZeroOffset and hourFormat).
> http://www.unicode.org/reports/tr35/tr35-dates.html#Primary_Zones
> http://www.unicode.org/cldr/charts/by_type/patterns.timezones.html#c394dccbd6c2e2d
>
> The GMT/UTC/UT prefixes are ZoneId forms, not directly related to
> offset printing and not really relevant here
>
> Stephen
>
>
> On 22 March 2013 20:22, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> Hi,
>>
>> I have not tried the "localized" resource for GMT yet (Masayoshi suggested
>> there are such l10n resources in JDK, but few in CLDR data...), just wonder
>> if this is the approach we want to go with to be"CLDR compatible" for zone
>> pattern letters Z[4, 5] and O[1, 4]
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/fmtOffsetPrefixed/
>>
>> -Sherman