[threeten-dev] Islamic calendar variants need disambiguation

[Dan Chiba]

Hi Stephen, Yoshito,

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