Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5042419

XMLGregorianCalendar: spec ambiguity in setting default field values

    Details

    • Subcomponent:
    • Resolved In Build:
      1.5
    • CPU:
      generic
    • OS:
      generic

      Backports

        Description

        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).

        ======================================================================

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  jsuttorsunw Jeff Suttor (Inactive)
                  Reporter:
                  reysunw Rey Rey (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: