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

[Stephen Colebourne]

This patch
https://gist.github.com/jodastephen/4691683
adds static methods to ChronoLocalDate and friends that help here (but
we can't push the patch yet).

The idea is that these bits of possible application code should work:
 formatter.parse(str, LocalDate::from)
 formatter.parse(str, JapaneseDate::from)
 formatter.parse(str, ChronoLocalDate::from)

In the first two, it doesn't matter what chronology the date parsed
to, just that a date is available, because the parameter specifies the
desired calendar system implicitly. In the last one, you'll get a
ChronoLocalDate with the "requested" chronology (see earlier mail),
and that is the common case for Oracle's globalization team.

Note that all of the above is irrelevant of what the internal class is
(currently DateTimeBuilder) because it is only accessed as a
TemporalAccessor.

In an ideal world, DateTimeBuilder's resolving logic would disappear
and be merged into DateTimeParseContext. However, the "resolve" would
still need to be invoked only on demand so parseUnresolved() continued
to work.

Stephen


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