The spec for XMLGregorianCalendar is vague, or not as clear as java.util.Calendar which clearly states when interpretation will be made for the values set by setters. The spec for XMLGregorianCalendar stated that the constraints will be checked by factory methods, setter methods and parse methods, and that IllegalArgumentException is thrown if the composite values constitute an invalid XMLGregorianCalendar instance. To me, this statement is not clear enough as to when the values should be validated. For example, should setDay calls validate or should setMonth? It appears our impl did not. In fact, none of setters did the check except setHour. So, why should setHour call for validation?

The JCK test is arguably incorrect because it expects setHour to check values that may or may not have been set by other setters. By itself, 24 is a valid value! The setHour method should only be responsible for what it should know, that is "hour", not the calendar. The interpretation should not be made until the calendar needs to calculate its time value.

I traced back to a CR 6393386 filed exactly due to this test. Our impl was then changed in order to pass this test. The change made setHour a lonely setter that does a validation none of other setters do!

So I would agree with IBM, that the JCK test needs to be excluded or correct, and our impl changed back to previous state (e.g. rollback the change made for 6393386)

Thanks,
Joe

Leonid Kuskov wrote:
> Hello Santiago, Joe,
>
> I've just received the exclude request (CR 6897603) from IBM about code:
>
> -----------
> XMLGregorianCalendar calendar = df.newXMLGregorianCalendar();
> try {
> calendar.setHour(24);
> return Status.failed("setHour(24) does not throw IllegalArgumentException");
> } catch (IllegalArgumentException e) {
> return Status.passed("OK");
> }
> -----------
>
> SUN RI throws IllegalArgumentException as expected, IBM RI doesn't do it.
>
> IBM wants to change behavior of the XMLGregorianCalendar class:
>
>> Details from Licensee:
>> We request this test be excluded.
>>
>> The impact that this has on users is that it forces them to call set() methods in a particular order, which is not imposed for other parts of the class:
>>
>> For instance, an application may want to change a date from February 28th to March 31st. They can do that by calling
>>
>> XMLGregorianCalendar xgc = ...;
>> xgc.setDay(31);
>> xgc.setMonth(3);
>>
>> Note that before the setMonth() call the date is invalid (February 31st) but this is just a transient state of the object while the user is editing. The XMLGregorianCalendar.isValid() method was provided for checking whether the current state is valid. This is where co-constraints between the fields set in XMLGregorianCalendar are supposed to be checked, such as whether the value of the day is allowed for the current month, or if the date is February 29th, if the year field is actually a leap year which has such a date. Checking if hour = 24, that minute = 0, second = 0 should be done in the isValid() method too.
>>
>> It appears that when Sun allowed '24' to be specified as a value for hours in Java 6 that their implementation of setHour() checks whether minutes = 0, hours = 0 at the point in time the user calls this method. So someone attempting to change a time from lets say 23:59:59 to 24:00:00 is forced to do it this way:
>>
>> XMLGregorianCalendar xgc = ...;
>> xgc.setSecond(0)
>> xgc.setMinute(0);
>> xgc.setHour(24);
>>
>> and would get an exception if they tried another order:
>>
>> XMLGregorianCalendar xgc = ...;
>> xgc.setHour(24);
>> xgc.setMinute(0);
>> xgc.setSecond(0)
>>
>> We feel this is an unnecessary constraint which is inconsistent with other behaviour of the class. This contradicts other behaviour for this class where one can set the value of days = 31 in month 2 (i.e. Feburary 31st) before reassigning the month value to a valid month. When we checked what the Sun implementation we found that although it would throw an exception here it sets the value of hours to 24 anyway, so actually isn't blocking this mutation.
>>
>> Similarly if someone wrote:
>>
>> XMLGregorianCalendar xgc = ...;
>> xgc.setSecond(0)
>> xgc.setMinute(0);
>> xgc.setHour(24);
>> xgc.setMinute(3);
>>
>> A time of 24:03:00 the Sun implementation allows this too, so it's not even effectively blocking the user when they change the value of the fields in other ways. Hence we believe this is an unnecessary constraint and so this test be excluded in JCK 6b.
> The behavior of SUN implementation conforms to the specification:
> -------------
> hour - 0 to 24 or DatatypeConstants.FIELD_UNDEFINED. For a value of 24, the minute and second field must be zero per XML Schema Errata.
> day - Independent of month, max range is 1 to 31 or DatatypeConstants.FIELD_UNDEFINED. The normative value constraint stated relative to month field's value is in W3C XML Schema 1.0 Part 2, Appendix D.
> min - 0 to 59 or DatatypeConstants.FIELD_UNDEFINED
> --------------
>
> From the other hand, all IBM arguments make sense...
>
> I'm getting to reject this exclude request, but the last code snippet
>
>> xgc.setSecond(0)
>> xgc.setMinute(0);
>> xgc.setHour(24);
>> xgc.setMinute(3);
>>
> looks as the specification defect.
>
> Since the setMinute/setSecond/setFractionalSecond??/setMillisecond?? methods contradict the assertion :
> "hour - 0 to 24 or DatatypeConstants.FIELD_UNDEFINED. For a value of 24, the minute and second field must be zero per XML Schema Errata."
> I'm going to file a CR against specification.
>
> What do you think about this case?
>
> Thanks in advance,
> Leonid