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

[Roger Riggs]

HI Masayoshi,

On 02/04/2013 07:39 PM, Masayoshi Okutsu wrote:
> Hi Roger,
>
> Any chance to include the following changes in the CCC request for M7?
>
> - Remove DateTimeFormatterBuilder.appendLocalized(FormatStyle, 
> FormatStyle, Chronology).
Removed.
>
> - Remove the following paragraph from 
> DateTimeFormatterBuilder.appendLocalized(FormatStyle, FormatStyle).
>
>      * <p>
>      * The pattern can vary by chronology, although typically it doesn't.
>      * This method uses the standard ISO chronology patterns.
This comment has already been modified to remove the reference to ISO.
"     * <p>
      * The pattern can vary by chronology, although typically it doesn't.
      * This method allows the chronology to be specified.
"

Is that adequate or should the description be removed?

Thanks, ROger


>
> There should be more documentation for the runtime behavior with 
> localized formats, but it should be deferred to post-M7.
>
> Thanks,
> Masayoshi
>
>
> 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
>