[threeten-dev] Review request for changes to support Hijrah variants

[Dan Chiba]

Hi Roger,

I agree it is a good solution to have this as the longest month found in 
the variant definition.

Thanks,
-Dan

On 2/16/2013 9:00 AM, roger riggs wrote:
> Hi Dan,
>
> The Threeten API does not presently try to accommodate that technique
> for dealing with that aspect of Islamic tradition.  But it is similar 
> to several other calendars,
> mostly Lunar-Solar calendars that have variations in the month 
> sequence/numbers.
> For example, the traditional Chinese calendar and various Indian 
> calendars.
>
> I expect that an effective approach for those is that formatter would 
> be able
> to parse and format the date as expected by the human reader but that 
> the numeric
> sequence would be strictly sequential.
>
> The code referenced should not be hard coded but be computed from the
> calendar as it as read (but the result would be about the same).
>
> Roger
>
> On 2/15/2013 9:02 PM, Dan Chiba wrote:
>> Hi Roger,
>>
>> HijrahChronology.java
>>>   652     int getMaximumDayOfMonth() {
>>>   653         return 30;
>>
>> At R.H. van Gent's website 
>> <http://www.staff.science.uu.nl/%7Egent0113/islam/ummalqura.htm>, it 
>> says:
>>
>> "In some cases the advancement of the month can result in a month 
>> length of 31 days which is awkward as Islamic tradition only allows 
>> for month lengths of 29 or 30 days. In such cases one of the days in 
>> the month is reckoned twice. For instance, both Friday 28 December 
>> and Saturday 29 December 2007 were reckoned as 19 Dhū ’l-Ḥijja 1428 AH."
>>
>> This sounds astounding; I don't think 310 could support same date for 
>> two days, while a month longer (or shorter) than standard lengths 
>> might be supported.
>>
>> Thanks,
>> -Dan
>>
>> On 2/15/2013 1:16 PM, roger riggs wrote:
>>> Hi,
>>>
>>> Please review the changes to support multiple Islamic calendar 
>>> variants:
>>>  - Only the Umm alQura variant is supported so far and is supported 
>>> by limited
>>>    placeholder data until the full data can be acquired and validated.
>>>  - Tests have been updated to work with the updated API and 
>>> available data
>>>  - The use of Locale 'ca' and 'cv' values has been added to 
>>> Chronology.ofLocale
>>>  - Properties are added to lib/calendars.properties to identify the 
>>> variants
>>>    by calendar type and to identify the resource containing the 
>>> calendar data.
>>>
>>> Webrev: http://cr.openjdk.java.net/~rriggs/webrev-hijrah-variants/
>>>
>>> Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-hijrah-variants/
>>>
>>> Note: there are several related issues to be addressed after this 
>>> change:
>>>  - The API for Era.date(xxx) does not lend itself to support of 
>>> calendars
>>>    with multiple variants; Eras do not have any knowledge of a 
>>> specific chronology
>>>  - Performance of initialization at startup
>>>  - Enumerations of Eras
>>>
>>
>