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

[Stephen Colebourne]

Masayoshi,
Do you want to send me anything to review so far? I may be able to
assist better that way.

Re-reading my earlier email, I made a mistake with the "requested"
chronlogy definition.

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

But it should have been:
The "requested" chronology is the chronology of
DateTimeFormatter.withChronology()

(no ISO fallback)

Stephen


On 7 February 2013 00:25, Stephen Colebourne <scolebourne at joda.org> wrote:
> 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
>>>>
>>>>
>>