[threeten-dev] Islamic calendar variants need disambiguation

[Stephen Colebourne]

The string can be anything you want, as its more of an Oracle
requirement than mine.

Personally, I would recommend that Oracle chooses a default Islamic
calendar variant, so the string "islamic" maps to one of the variants.
I would then have the other variants as "islamic-xxx". The ca and cv
parts in the 310 calendar system id are not really relevant.

Stephen


On 11 January 2013 20:49, Dan Chiba <dan.chiba at oracle.com> wrote:
> Thank you very much Yoshito-san.
>
> Stephen, can the single string be "ca-islamic-cv-???"? Then all we need to
> do may be define the ???s?
>
> Regards,
> -Dan
>
>
> On 1/10/2013 5:20 PM, Stephen Colebourne wrote:
>>
>> On 10 January 2013 21:04,<yoshito_umaoka at us.ibm.com>  wrote:
>>>
>>> We had a discussion about this in the CLDR TC meeting.
>>> Our tentative consensus is supporting calendar variations with a new
>>> extension.
>>>
>>> Although CLDR defines two types "islamic" and "islamicc", CLDR only has
>>> one set of formatting data. From formatting aspect, the difference in
>>> date
>>> calculation between them is not important. Our current plan is:
>>>
>>> 1. Add a new extension "cv" (calendar algorithm variant - tentative).
>>> 2. Investigate necessary types from experts, based on some references
>>> including your ticket above.
>>> 3. Deprecate "islamicc", and map to ca-islamic-cv-??? (??? will be
>>> determined later).
>>>
>>> Note that the type value is limited to 8 characters because of BCP 47
>>> definition. We also considered multi-segment calendar type like
>>> islamic-umalqura as you suggested in the ticket, but it will require a
>>> bunch of duplicated references in CLDR data formatting data. For this
>>> reason, we are in favor of separating minor algorithm differences in a
>>> separate extension.
>>
>> FWIW, I like the "cv" variant concept as it makes logical sense. It
>> will be harder to integrate into JSR-310 (where our methods take a
>> single String). The lookup from a Locale object will of course pose no
>> problem to adapt.
>>
>> Stephen