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

[Masayoshi Okutsu]

I've already changed the parser code to be Chronology-aware and to 
utilize localized patterns and names from CLDR resources. I'm at the 
last phase of the parsing which creates a LocalDate from various 
date-time parameters.

My question is, what's the final form of the produced DateTimeBuilder? 
In theory, you can obtain a ChronoLocalDate from a DateTimeBuilder 
containing a Chronology and a LocalDate. Is that the final form?

Thanks,
Masayoshi

On 2/6/2013 11:23 PM, Stephen Colebourne wrote:
> 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
>>