[threeten-dev] Islamic calendar variants need disambiguation

[Stephen Colebourne]

This plan looks fine to me,

There is a separate discussion around what the chronology ID will be,
currently "Hijrah" (the strings in your email are the calendar system
ID).

I do think that it is important that if the Locale has a ca code, but
not a cv code, then it should map to something sensible.

Stephen



On 12 January 2013 01:35, Dan Chiba <dan.chiba at oracle.com> wrote:
> For 310, we like the approach to use "islamic" for the primary variant and
> using "islamic-xxx" for others.
> We would like to propose a few details to fit to the CLDR ca/cv separation
> as follows:
>
>  310             CLDR                  Description
>  -------------   --------------------  ---------------------------------
>  islamic         ca-islamic-cv-uaq     Umm Al-Qura
>  islamic-sa      ca-islamic-cv-sa      Saudi Arabia Sighting
>  islamic-???     ca-islamic-cv-???     "???" denotes a specific variant.
>
>
> * Chronology.of() takes a 310 string. In JDK8 "islamic" and "islamic-sa" are
> the only defined variants.
> * Chronology.ofLocale() creates the specified variant if the locale has the
> CLDR designation inside.
> * The variant identifier must be in lowerecase and can be 2 to 8 letters
> long.
> * The IANA region codes are reserved. A region other than "sa" may have a
> variant.
> * 310 and CLDR plan to identify the common variants.
>   (e.g. "kuwaiti" may be in high demand and become the next defined variant.
> The list may grow.)
> * Users who need a user defined variant may use a custom ID at their own
> risk.
>   They are encouraged to request getting the ID registered.
> * 310 could have "islamic-uaq" as an alias of "islamicc" to match the
> defaulting for deprecation in CLDR.
> * 310 could have "islamic-uaq" as an alias of "islamic" to help achieve
> consistent mapping from CLDR to 310.
> * The registration/maintenance process is TBD.
>
> May I ask if this looks something we can settle this with?
>
> Regards,
> -Dan
>
>
> On 1/11/2013 2:01 PM, Stephen Colebourne wrote:
>>
>> 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