[threeten-dev] Clarification request: DateTimeFormatter.ofLocalizedDate/Time behavior

[Masayoshi Okutsu]

The formatting part is now working to produce correct non-ISO dates with 
CLDR resources. I will need to test more, though.

Now I'm working on the parsing part. Parsing seems to have similar ISO 
Chronology assumptions. For example, parsing a Hijrah date string 
produces a DateTimeBuilder containing a LocalDate with the parsed Hijrah 
year value, like 1434-02-04. No Chronology information. I've changed 
mergeDate() to produce a DateTimeBuilder containing the Hijrah 
Chronology and a LocalDate with its ISO date 2012-12-18. But I'm 
wondering if that's what intended to be produced.

Thanks,
Masayoshi

p.s. Currently, parsing Japanese dates is hopeless. The parser produces 
0025-02-06 (ISO) from Heisei 25-02-06 and throws an exception as an 
invalid (inconsistent) date...

On 2/5/2013 8:45 AM, Stephen Colebourne wrote:
> On 4 February 2013 23:35, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
>> ofLocalizedDate() invokes DTFormatterBuilder().appendLocalized(dateStyle,
>> null) which specifies the ISO Chronology as specified by appendLocalized.
>> Then, the ISO Chronology is always used when looking up a pattern.
>> withChronology doesn't change the Chronology. But neither ISO nor the given
>> Chronology by withChronology should be used for actual formatting?
>>
>> Looks like a structural problem in the API design rather than an
>> implementation problem? Or am I just confused?
> OK, I see the problem you refer to now.
>
> appendLocalized(FormatStyle dateStyle, FormatStyle timeStyle) is wrong
> and should use the chronology of the target temporal, which will be
> affected by withChronology().
>
> appendLocalized(FormatStyle dateStyle, FormatStyle timeStyle,
> Chronlogy chrono) should be deleted AFAICT.
>
> Stephen