The Hijri calendar could have a calendar system type of "islamic", "islamic-civil", "arabic", "arabic-civil" or "islamicc". Clarify which it should be.
name="islamicc" alias="islamic-civil" description="Civil (algorithmic) Arabic calendar"
The other type is "Astronomical Arabic calendar" while (quoting javadoc) "the implementation follows the Freeman-Grenville algorithm".
Fixed by a543e8e
Fix chronology test
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.
CLDR Ticket #5525 opened:
Here is the updated proposed identification scheme for the Hijrah variants.
The outlines are as follows:
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.
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.
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.
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.
Thank you Stephen. Revised for the chance to have other variants in an update release on JDK8.
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
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.
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.
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.
Has this settled enough to be 'Approved'; I've got a most of it implemented.
I'm happy to look at webrevs. The strategy here is pretty well settled I think.
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.
The variant ID for the Saudi Arabia sighting variant has been updated from "sg0" to "rgsa".
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
I think all the issues are resolved; If there are any remaining issues please create a new issue.
The full Umm AlQura data is submitted in http://hg.openjdk.java.net/threeten/threeten/jdk/rev/32edb634b3c3