[threeten-dev] Non-webrev: Change yyyy to uuuu

[Masayoshi Okutsu]

On 2/20/2013 4:31 PM, Stephen Colebourne wrote:
> On 20 February 2013 00:48, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
>> I haven't looked at code changes yet, but I noticed the following test data
>> change.
>>
>> - { "\u662d\u548c64\u5e741\u67089\u65e5\u6708\u66dc\u65e5" }, // S64.01.09
>> (Mon)
>> + // line commented out, as S64.01.09 seems like a reasonable thing to parse
>> + // (era "S" ended on S64.01.07, but a little leniency is a good thing
>> +// { "\u662d\u548c64\u5e741\u67089\u65e5\u6708\u66dc\u65e5" }, // S64.01.09
>> (Mon)
>>
>> What's the reason behind this change? Is there any way to validate given
>> Japanese calendar dates?
> I'd be happy for further suggestions here, given I don't read Japanese ;-)
>
> As far as I can tell,  S64.01.06 is a valid Japanese date, but
> S64.01.09 is after the start of the new era, whereas  S65.01.09 is
> definitely after the start of the new era.
>
> The old code seemed to reject both the "invalid" ones. The new code is
> more lenient, only rejecting based on the year. So,  S64 is valid
> because some dates in that year are valid, whereas S65 is invalid
> because no dates in that year are valid.
>
> Seem reasonable?

My understanding is that the default behavior of DateTimeFormatter is 
strict. Neither should be accepted. Am I correct?

> (See also the changes in JapaneseChronlogy)

That change should be correct. The normalize() call can be removed and 
the method can return gregorianYear. But the method needs to be changed 
to correctly handle the 310 year range. I will take a look at it.

Masayoshi

>
> Stephen