Hi Stephen,
I also indicated in the Jira comments that it is misleading and
incorrect to return
false when it is not known that a year is or is not a leap year. All of
the other
HijrahChronology computations throw DTE for invalid dates and the same
may be
true for other Chronologies.
The assertion in Chronology.isLeapYear about not checking the range is
too broad
and should be qualified by the Chronology.
Perhaps the proposed change should include a caveat in that method.
Roger
On 2/3/15 8:05 PM, Stephen Colebourne wrote:
-1
As I indicated on JIRA, I don't believe that this change meets the
spec or intent of the definition on Chronology. That is specified to
not throw any exceptions and to handle all years, valid or not.
I don't foresee any significant issue where a year is not validated by
this method. Years out of range should simply return false, again
something that is within the spirit of the spec "a chronology that
does not support the concept of a year must return false."
Stephen
On 3 February 2015 at 20:56, Lance Andersen <lance.ander...@oracle.com> wrote:
+1
On Feb 3, 2015, at 3:45 PM, Roger Riggs <roger.ri...@oracle.com> wrote:
Please review this specification clarification of the range of Hijrah calendar
variants.
The issue was exposed by a bug in the HijrahChronology.isLeapYear method.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-leap-year-8067800/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8067800
A CCC may be needed.
Thanks, Roger
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
