-
Bug
-
Resolution: Fixed
-
P3
-
5.0
-
1.5
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2119633 | 1.3.0 | Jeff Suttor | P3 | Resolved | Fixed | 1.3 |
Name: erR10175 Date: 05/05/2004
In the javax.xml.datatype.XMLGregorianCalendar's javadoc of the method
public GregorianCalendar toGregorianCalendar()
there is an ambiguity in determining default field values of the created
GregorianCalendar instance.
The javadoc of the method reads:
"
When this instance has an undefined field, this conversion relies on the
java.util.GregorianCalendar default for its corresponding field.
...
Initialize all GregorianCalendar fields to 0 by calling setTimeInMillis(0L).
"
But according to the spec of the method setTimeInMillis(long millis) in the
Calendar class
"
an instant in time can be represented by a millisecond value that is an offset from
the Epoch, January 1, 1970 00:00:00.000 GMT (Gregorian).
"
Note, that the Epoch is specified along with timezone GMT. Thus, setting time to 0
milliseconds does not mean setting the fields to default values 1970-01-01 00:00:00.
Instead, that means that the result will represent the Epoch in the calendar's
timezone. For example (see the test and its log below) for SST(+11:00) the dateTime
will be January 1, 1970 11:00:00.000 GMT.
------------------------------------ test.java
import java.util.GregorianCalendar;
class test {
public static void main(String [] args) {
GregorianCalendar c = new GregorianCalendar();
c.setTimeInMillis(0L);
System.out.println("new GregorianCalendar().setTimeInMillis(0L) results in "
+ c.get(GregorianCalendar.YEAR)
+ "-" + (c.get(GregorianCalendar.MONTH) - GregorianCalendar.JANUARY + 1)
+ "-" + c.get(GregorianCalendar.DAY_OF_MONTH)
+ "T" + c.get(GregorianCalendar.HOUR)
+ ":" + c.get(GregorianCalendar.MINUTE)
+ ":" + c.get(GregorianCalendar.SECOND)
+ " " + c.getTimeZone().getID());
}
}
----------------------------------------------
------------------------------------------ log
$javac test.java && java -Duser.timezone=SST -showversion test
java version "1.5.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b49)
Java HotSpot(TM) Client VM (build 1.5.0-beta2-b49, mixed mode)
new GregorianCalendar().setTimeInMillis(0L) results in 1970-1-1T11:0:0 SST
----------------------------------------------
The spec should get rid of the ambiguity. It would be better to use
the method Calendar.clear() instead of the Calendar.setTimeInMillis(long).
The following two new JCK tests mentioned in the fixed bug
5030130 XMLGregorianCalendar.toGregorianCalendar methods do not set default values
api/javax_xml/datatype/XMLGregorianCalendar/index.html#ConvertTo[ToGregorianCalendar006]
api/javax_xml/datatype/XMLGregorianCalendar/index.html#ConvertTo[ToGregorianCalendar007]
still fail because they expect default field values (i.e. 1970-01-01 00:00:00) regardless
of the time zone but RI seems to be using setTimeInMillis(0L).
======================================================================
In the javax.xml.datatype.XMLGregorianCalendar's javadoc of the method
public GregorianCalendar toGregorianCalendar()
there is an ambiguity in determining default field values of the created
GregorianCalendar instance.
The javadoc of the method reads:
"
When this instance has an undefined field, this conversion relies on the
java.util.GregorianCalendar default for its corresponding field.
...
Initialize all GregorianCalendar fields to 0 by calling setTimeInMillis(0L).
"
But according to the spec of the method setTimeInMillis(long millis) in the
Calendar class
"
an instant in time can be represented by a millisecond value that is an offset from
the Epoch, January 1, 1970 00:00:00.000 GMT (Gregorian).
"
Note, that the Epoch is specified along with timezone GMT. Thus, setting time to 0
milliseconds does not mean setting the fields to default values 1970-01-01 00:00:00.
Instead, that means that the result will represent the Epoch in the calendar's
timezone. For example (see the test and its log below) for SST(+11:00) the dateTime
will be January 1, 1970 11:00:00.000 GMT.
------------------------------------ test.java
import java.util.GregorianCalendar;
class test {
public static void main(String [] args) {
GregorianCalendar c = new GregorianCalendar();
c.setTimeInMillis(0L);
System.out.println("new GregorianCalendar().setTimeInMillis(0L) results in "
+ c.get(GregorianCalendar.YEAR)
+ "-" + (c.get(GregorianCalendar.MONTH) - GregorianCalendar.JANUARY + 1)
+ "-" + c.get(GregorianCalendar.DAY_OF_MONTH)
+ "T" + c.get(GregorianCalendar.HOUR)
+ ":" + c.get(GregorianCalendar.MINUTE)
+ ":" + c.get(GregorianCalendar.SECOND)
+ " " + c.getTimeZone().getID());
}
}
----------------------------------------------
------------------------------------------ log
$javac test.java && java -Duser.timezone=SST -showversion test
java version "1.5.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b49)
Java HotSpot(TM) Client VM (build 1.5.0-beta2-b49, mixed mode)
new GregorianCalendar().setTimeInMillis(0L) results in 1970-1-1T11:0:0 SST
----------------------------------------------
The spec should get rid of the ambiguity. It would be better to use
the method Calendar.clear() instead of the Calendar.setTimeInMillis(long).
The following two new JCK tests mentioned in the fixed bug
5030130 XMLGregorianCalendar.toGregorianCalendar methods do not set default values
api/javax_xml/datatype/XMLGregorianCalendar/index.html#ConvertTo[ToGregorianCalendar006]
api/javax_xml/datatype/XMLGregorianCalendar/index.html#ConvertTo[ToGregorianCalendar007]
still fail because they expect default field values (i.e. 1970-01-01 00:00:00) regardless
of the time zone but RI seems to be using setTimeInMillis(0L).
======================================================================
- backported by
-
JDK-2119633 XMLGregorianCalendar: spec ambiguity in setting default field values
- Resolved
- relates to
-
JDK-5030130 XMLGregorianCalendar.toGregorianCalendar methods do not set default values
- Resolved