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

[Stephen Colebourne]

Parsing non-ISO is currently completely unsupported as a known issue.
https://github.com/ThreeTen/threeten/issues/241
Its just something I didn't get around to.

The logic for parsing the date should involve two levels of chronology
processing.

Firstly, the year, month and day have to be merged together (and
similar fields) using the "parsing" chronology. Then the result may
have to be converted to the "requested" chronology.

The "parsing" chronology is the first non-null of:
- the result of parsing from DTFB.appendChronoId()
- the chronology of DateTimeFormatter.withChronology()
- IsoChronology
See DateTimParseContext.getEffectiveChronology() to obtain this.

The "requested" chronology is the first non-null of:
- the chronology of DateTimeFormatter.withChronology()
- IsoChronology

Thus, this date: "1234-06-30 Minguo" would have a "parsing" chrono of
"Minguo" as that is part of the text being parsed. If it was parsed
using this:
 formatter.withChronology(JapaneseChronlogy.INSTANCE)
then the result visible in the TemporalAccessor/DateTimeBuilder would
be the Japanese date equivalent to the Minguo date 1234-06-30.

This logic will have to be documented in the spec/Javadoc.

In addition, we're going to have to have a fallback for a missing era,
so that the pattern letter "y" can be used for year-of-era without
also specifying "G", as per CLDR.

Keep in touch to let me know if I need to write some of this.
Stephen



On 6 February 2013 14:02, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
> 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
>
>