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

[Stephen Colebourne]

So, how do Japanese businesses handle dates in the future? Any future
Japanese date can become invalid overnight depending on an "event"
over which no-one has control.

Personally, I think it would make most sense to support full leniency.
Any year-of-era is valid, its simply relative to the base year for
that era (with the output normalized to a different era). ie S79-06-06
parses and normalises to H13-06-06.

Perhaps this is part of the broader strict vs lenient date resolution
that is still an open issue.

Stephen



On 22 February 2013 03:49, Masayoshi Okutsu <masayoshi.okutsu at oracle.com> wrote:
> What I mean is that it's not a correct approach to convert Japanese era and
> year-of-era values to their corresponding proleptic Gregorian year for
> creating a LocalDate.
>
> Your leniency reason for Japanese date validation doesn't make sense at all.
> It's rather a problem in Japanese businesses. The test case commented out
> must be restored.
>
> Thanks,
> Masayoshi
>
>
> On 2/21/2013 10:07 PM, Stephen Colebourne wrote:
>>
>> Not sure of your point.
>> The code still assumes the current era if YEAR_OF_ERA is received without
>> ERA.
>>
>> Stephen
>>
>>
>> On 21 February 2013 05:45, Masayoshi Okutsu <masayoshi.okutsu at oracle.com>
>> wrote:
>>>
>>> I now understand where the Japanese date validation problem comes from. I
>>> don't think this approach is correct. 'y' is now bound to YEAR_OF_ERA,
>>> era-based date computation is inevitable. If ERA isn't given explicitly,
>>> the
>>> current ERA should be assumed.
>>>
>>>
>>> Masayoshi
>>>
>>> On 2/20/2013 1:20 AM, Stephen Colebourne wrote:
>>>>
>>>> See patch
>>>> https://gist.github.com/jodastephen/4987319
>>>>
>>>> Issue:
>>>> https://github.com/ThreeTen/threeten/issues/138
>>>>
>>>> I'd love to carry on and do more changes, but thats not practical
>>>> until this one is reviewed and committed...
>>>>
>>>> Stephen
>>>
>>>
>