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

[Roger Riggs]

Hi Stephen,

On 2/20/13 3:03 AM, Stephen Colebourne wrote:
> On 19 February 2013 18:48, roger riggs<roger.riggs at oracle.com>  wrote:
>> public ValueRange range(ChronoField field) is incorrect wrt retaining
>> the BEFORE era
>>
>> Please recheck, updated to include the full range of Year in the smallest
>> min and greatest max to allow for different calendars.
>> (Unless I misunderstand).
> I think your original range from getMinYear() to getMaxYear() was
> correct. My point was that the range doesn't vary based on the
> temporal, so it only needs to be defined in the chronology. Plus my
> second point was that the defined range is only accurate once the
> BEFORE ERA is removed.
Right, the range support in HijrahDate was removed and delegates to the 
HIjrahChronology.

I didn't see it would make a difference in the range, since there are no
years in the calendars that would fall into the BEFORE_AH Era.
>   case YEAR:
>   case YEAR_OF_ERA:
>     return ValueRange.of(getMinimumYear(), getMaximumYear());
>
> I do note that many Hijrah variants are just algorithmic, so I'm not
> certain that the file format you are using (specifying every known
> year) will be practical for the algorithmic variants.
Most of the algorithms I have seen define the year range of their accuracy.
For example, don't use before 10 H, and with variations in the lunar cycles,
though minor, I would expect most authorities not to declare they are valid
for many centuries.

Roger

> Stephen