[threeten-dev] CLDR Islamic calendar types

[Dan Chiba]

On 1/28/2013 2:25 PM, yoshito_umaoka at us.ibm.com wrote:
> > Ok, I was only aware of BCP47:
> >  extension     = singleton 1*("-" (2*8alphanum))
>
> Yes, this is the BCP 47 base syntax.
>
> > Is it correct that the Unicode extension tightens this rule to 3 to
> > 8 letters (in RFC6067 section 2.1, first bullet)?
>
> Complete syntax definition for u (and t) extension is found at section 
> 3 in the LDML specification:
>
> http://www.unicode.org/reports/tr35/#Unicode_Language_and_Locale_Identifiers 
>
>
> The Unicode locale extension may consist from attributes and keywords.
> Each keyword consists from key and optional type.
>
> We want to support well-formedness check without having complete 
> subtag repository, we decided to limit keys to be always 2 letter 
> code, and attributes and type subtags to be 3 to 8 characters. For 
> example, following language tag is well-formed (but not valid because 
> of subtags are not registered in the locale extension registry).
>
Thank you; I was not fully aware of this.
> en-u-abc-xyz-aa-bbb-ccc-dd-ee-fff
>
> Above is parsed into -
>
> language: en
>
> Unicode extension:
>   attribute: abc
>   attribute: xyz
>   keyword: key=aa / value=bbb-ccc
>   keyword: key=dd
>   keyword: key=ee / value=fff
>
> As you many know, the parser is implemented in java.util.Locale class 
> in JDK 7.
>
> > Yes, I think this is helpful, although currently we only plan to
> > support "sa0" for this kind.
>
> I'm wondering what is the implication of Islamic Calendar based on 
> sighting used in Saudi Arabia in the context of JSR-310.
> There is no good way to calculate future dates with this - of course, 
> it might be still valid for past dates (as long as Java is providing 
> updates when new month is officially determined in Saudi Arabia). How 
> would you implement this as a chronology in the JSR-310 framework?
>
All future dates are valid, it's just that their mappings to other 
calendars may change. And a 30th day of the month may be removed, if 
starting a new month (becomes the first day of the next month) is announced.
> In my honest opinion, I'm not sure it is worth distinguishing one 
> sighting based dates used at region A from another sighting based 
> dates used at region B. Neither of them is predictable by software. 
> Isn't it better to just put them into one bucket as - sighting 
> based/religious calendar?
Distinguishing is required to not confuse distinct variants. The same 
date in different variants may actually be different dates so they are 
not interchangeable. JSR-310 intends to enable reliably exchanging 
islamic date information by identifying the variant unambiguously. If 
different variants are put in the same bucket, applications can confuse 
the variants and result in an unexpected behavior.

Despite the characteristic to make software unable to predict the 
deviations, sighting is still in use.
>
>
> > I think it is great if CLDR can define cv values in bcp47/*.xml.
>
> Of course, when they are added into the registry, some explanation of 
> the types should be provided.
>
> > Would it be reasonable to have a longer description as well, so more
> > information can be added? If this long description field can carry a
> > reference to the full specification, no external registry would be 
> necessary.
>
> It's obviously impossible to spell out the complete algorithm there.
> Of course, we try to eliminate ambiguity as much as possible, in short 
> description.
> For example, the registry does not try to explain what is Gregorian 
> calendar.
>
May I request inclusion of "umalqura" and "sa0"?

The description can be the "Umm Al-Qura calendar" and "the islamic 
calendar based on the announcement by the High Judiciary Council of 
Saudi Arabia", respectively.

Regards,
-Dan
> -Yoshito
>