[threeten-dev] DateTimeFormatter.withLocale question

[roger riggs]

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