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

[Masayoshi Okutsu]

On 2/22/2013 7:46 PM, Stephen Colebourne wrote:
> 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.

I think the current practice is to store dates in Gregorian and perform 
conversions where Japanese dates are required. For example, spread 
sheets store dates in Gregorian, but display those in the Japanese 
calendar if any Japanese date format is given.

So the formatting and parsing are still important functionality for 
Japanese businesses. For example, birth date validation is an important 
operation. If the given birth date is S64.01.08, it must be rejected.

> 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.

When I was working on Japanese calendar support for JDK 6, someone 
proposed per-field leniency. For example, era and year values are OK to 
change by normalization, but other fields are not. I found it was an 
interesting idea, but haven't had a chance to support it.

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

Do you plan to provide a solution for that in JDK 8? If not, the parser 
should be either strict or lenient. It's confusing if strict and lenient 
are dependent on given dates.

Masayoshi

>
> 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
>>>>