[threeten-dev] DateTimeFormatter.withLocale question

[Stephen Colebourne]

The DateTimeFormatSymbols issue is effectively the issue around number formats.
Stephen

On 22 February 2013 22:00, roger riggs <roger.riggs at oracle.com> wrote:
> Hi,
>
> If the number formatting is set separately from the rest of the locale
> I suppose we should have an issue for it and work on a design.
>
> Roger
>
>
> On 2/14/2013 1:39 PM, Stephen Colebourne wrote:
>>
>> On 13 February 2013 05:16, Masayoshi Okutsu <masayoshi.okutsu at oracle.com>
>> wrote:
>>>
>>> On 2/13/2013 7:38 AM, Stephen Colebourne wrote:
>>>>>>
>>>>>> DateFormat/SimpleDateFormat doesn't distinguish between the two
>>>>>> AFAICT,
>>>
>>> Traditionally DateFormat/SimpleDateFormat does. You have to set its
>>> NumberFormat to another one with a different numbering system, which is
>>> actually similar to the current DateTimeFormat design.
>>>
>>> As Naoto pointed out, you can specify different setting with a Locale
>>> value
>>> in JDK 8. For example, "en-u-ca-japanese-u-nu-thai" specifies to use the
>>> Japanese calendar with English date-time format patterns using the Thai
>>> digits (numbering system).
>>>
>>> My question is actually the behavior of withLocale(). We decided that the
>>> calendar type specified with the given Locale does NOT affect the
>>> DateTimeFormat. Then, I wanted to confirm if the same thing is applicable
>>> to
>>> the numbering system specified by the given Locale. That is, you have to
>>> specify a DateTimeFormatSymbols created for another numbering system in
>>> order to change the numbering system of a DateTimeFormat from
>>> DateTimeFormatSymbols.STANDARD.
>>
>> Since withLocale(Locale) does NOT set the chronology, it should also
>> NOT set the numbering system.
>>
>> However, there may be a role for a method withLocaleExtensions(Locale)
>> or withFullLocale(Locale) that takes into account the calender system
>> and numbering system versions.
>>
>> Stephen
>
>