Confirm calendar system type of islamic

[jodastephen]

The Hijri calendar could have a calendar system type of "islamic", "islamic-civil", "arabic", "arabic-civil" or "islamicc". Clarify which it should be.

[dchiba]

name="islamicc" alias="islamic-civil" description="Civil (algorithmic) Arabic calendar"

source: http://unicode.org/repos/cldr/trunk/common/bcp47/calendar.xml

The other type is "Astronomical Arabic calendar" while (quoting javadoc) "the implementation follows the Freeman-Grenville algorithm".

[jodastephen]

Fixed by a543e8e

[dchiba]

I am afraid it was a mistake to plan using "islamicc" all the time. 310 needs to identify the specific variants unambiguously, because the dates vary by the variant even if they are actually referring to the same day. At least the supported variants must have a formal ID assigned to disambiguate them, otherwise the dates can be confused.

A major issue here is that the variants are not identified in any IT standard clearly enough for the purpose of 310. CLDR does not assign names for each variant.

To resolve this variant identification problem, a subtag could be appended to islamicc/islamic; for example:

islamicc-ummalqura  ... Umm al-Qura
islamicc-kuwaiti    ... Kuwaiti variant
islamicc-famouse    ... Famouse variant
islamicc-<tbd>      ... Other calculation based variants, where <tbd> identifies 
                        a rule based variant
islamic-sa          ... Traditional variant for Saudi Arabia, sighting based
islamic-<tbd>       ... Sighting based variant for other countries, where <tbd> 
                        is a standard region subtag.

The proposed CLDR mappings in JDK8 are islamicc-ummalquara and islamic-ca mapped to islamicc and islamic, respectively. Then in the meantime, we could pursue getting more CLDR IDs registered or having a precise international calendar registry created.

[dchiba]

CLDR Ticket #5525 opened:
http://unicode.org/cldr/trac/ticket/5525

[dchiba]

Here is the updated proposed identification scheme for the Hijrah variants.

The outlines are as follows:

• Uses "islamic" for the primary variant and "islamic-xxx" for others.
• The proposal includes a few details to fit to the CLDR ca/cv separation defined below.

Table: Summary of the Hijrah calendar variant identification scheme

310             CLDR                  Description 
-------------   --------------------  --------------------------------- 
islamic         ca-islamic-cv-uaq     Umm Al-Qura
islamic-sa0     ca-islamic-cv-sa0     Saudi Arabia Sighting 
islamic-???     ca-islamic-cv-???     "???" denotes a specific variant. 

Details:

• Chronology.of() takes a 310 string. In JDK8 "islamic" and "islamic-sa0" 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 3 to 8 letters long.
• For a region identified with a 2-letter BCP47 region subtag (such as "sa" for Saudi Arabia), the letter '0' (zero) is padded to make it 3 letter long.
• BCP47 region subtags 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 defaults to "islamic" to match the defaulting for deprecation in CLDR, in case no cv value is specified. This is the case no matter if the ca value is "islamic" or "islamicc".
• 310 recognizes "islamic-uaq" as an alias of "islamic".
• The registration/maintenance process is TBD.

[dchiba]

The table below has Stephen's feedback incorporated:

As we've discussed before, there are two parallel IDs. For example
"Coptic" and "coptic", or "Hijrah" and "islamic". The table needs
updating with another column for the chronology ID (essentially an
alias based around the 310 class name). The ID isn't limited to 8
letters, but it is probably easiest and simplest to re-use the cv
string. Thus "Hijrah-sa" would be an alias for islamic-sa" in the
of(String) factory method.

Stephen

Table: Summary of the Hijrah calendar variant identification scheme

Chronology ID    Standard ID       CLDR Standard Extension  Description 
---------------  ----------------  -----------------------  ---------------------------------
Hijrah-umalqura  islamic-umalqura  ca-islamic-umalqura      Umm Al-Qura
Hijrah-rgsa      islamic-rgsa      ca-islamic-rgsa          Saudi Arabia Sighting 
Hijrah-???       islamic-???       ca-islamic-???           "???" denotes a specific variant.

Details:

• Chronology.of() takes either a standard ID or a chronology ID.
• In the initial release of JDK8, "islamic", "islamic-umalqura" and "islamic-rgsa" are the only defined standard IDs.
• In the initial release of JDK8, "Hijrah", "Hijrah-umalqura" and "Hijrah-rgsa" are the only defined chronology IDs.
• Subsequent updates may be released with additional variants.
• 310 and CLDR plan to identify the common variants. For instance, "kuwaiti" may be in high demand and become the next defined variant. The list may grow.
• Umm Al-Qura is the default variant. "islamic" and "Hijrah"are accepted as an alias.
• Chronology.ofLocale() creates the specified variant if the locale has the CLDR designation inside.
• The standard variant ID must be in lowerecase and can be 3 to 8 letters long. The calendar prefix is always "islamic".
• For a region identified with a 2-letter BCP47 region subtag (such as "sa" for Saudi Arabia), the prefix "rg" precedes the region sugtag.
• The chronology ID has no restriction in case and length.
• The variant part of the Chronology ID is the same as the standard variant ID.
• BCP47 region subtags with a possible padding in the variant name space are reserved. A value other than "rgsa" may identify a variant.
• 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 defaults to Umm Al-Qura to match the defaulting for deprecation in CLDR, in case no specific variant is specified. This is the case no matter if the ca value is "islamic" or "islamicc".
• The registration/maintenance process is TBD.

[jodastephen]

This looks good to me. I assume you have someone in mind to implement it.

Can we leave the documentation open enough that an additional variant could be added in a JDK update release? That way users don't have to wait until JDK 9.

[dchiba]

Thank you Stephen. Revised for the chance to have other variants in an update release on JDK8.

[dchiba]

Revised to match the CLDR proposal to use "umalqura" not "uaq" for the Umm Al-Qura calendar.

CLDR proposal: http://cldr.unicode.org/development/development-process/design-proposals/islamic-calendar-types

[dchiba]

Revised the ID for Saudi Arabia sighting variant to "sa0" from "sa" to comply with the Unicode extension syntax. It requires the variant ID to be 3 to 8 letters long. "0" is added for padding.

[jodastephen]

Re-reading this, Microsoft uses the "kuwaiti" algorithm as the default. I'm concerned that a different default between the two major Enterprise systems will cause unexpected conversion issues.

[dchiba]

Resolving the possible conversion issues would require JSR-310 to support the "kuwaiti" variant. Then the application should be able to identify the distinct variants properly and the conversion should work as expected. Application's having to identify the variant is a potential point of failure, but I am not sure if that is something we should be concerned about. Microsoft does support "umalqura" and if they default to "kuwaiti" I guess it may be for some compatibility reasons. Our choosing "umalqura" as the default is based on its commonly used status. I think we need to look at if we can afford adding support for kuwaiti.

[RogerRiggs]

Has this settled enough to be 'Approved'; I've got a most of it implemented.

[jodastephen]

I'm happy to look at webrevs. The strategy here is pretty well settled I think.

[dchiba]

For support of Microsoft kuwaiti, we haven't find it needs to be supported although it may be desired. I agree some users may need it. JSR-310 guarantees compatibility among the supported variants so it may be reasonable to add kuwaiti to supported variants. I'll collect input if anyone has a concern in supporting kuwaiti. I could provide the variant definition .properties file if we settle to support it.

[dchiba]

The variant ID for the Saudi Arabia sighting variant has been updated from "sg0" to "rgsa".

[dchiba]

I just updated the table above to remove the "cv" key, to match the withdrawal in CLDR. The target release of the variant ID scheme is CLDR 24, scheduled for September 18.
CLDR ticket #5942 has the status. http://unicode.org/cldr/trac/ticket/5942

[RogerRiggs]

I think all the issues are resolved; If there are any remaining issues please create a new issue.

[RogerRiggs]

The full Umm AlQura data is submitted in http://hg.openjdk.java.net/threeten/threeten/jdk/rev/32edb634b3c3