[threeten-dev] DateTimeFormatter.withLocale question

[Masayoshi Okutsu]

On 2/13/2013 7:38 AM, Stephen Colebourne wrote:
> On 12 February 2013 22:34, Naoto Sato <naoto.sato at oracle.com> wrote:
>> On 2/12/13 8:05 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).

>>>   but 310 is trying to. I'm very open to design options in this
>>> area.
>> Starting from JDK8, DateFormat/SimpleDateFormat recognizes "-u-nu-xxxx"
>> Unicode locale keyword. While "text" are localized with the base locale,
>> numbers are formatted in "xxxx" script if available. I'd expect the similar
>> behavior in 310 the formatters.
> I agree. If SimpleDateFormat is doing that, so should 310. The
> question is whether DateTimeFormatSymbols should be exposed publicly
> to achieve it.

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.

Thanks,
Masayoshi