XMLGregorianCalendar years & seconds precision

[glassfishrobot]

Submitted by David Bau, entered initially by Joe Fialli.

Concerning javax.xml.datatypes.XMLGregorianCalendar:

To permit correct behavior on validation tests, it is important that, like
Duration, the calendar type be able to handle large years and more than
three digits of fractional seconds; it would also be optimal if the number
of significant digits of seconds were remembered, so that dates can be
nicely round-tripped to XML. I recommend that this information be able to
be held by the XmlGregorianCalendar implmentation and accessible by its own
API, but truncated when queried by the ordinary Calendar API.

Environment

Operating System: All
Platform: All

Affected Versions

[2.0 draft]

[glassfishrobot]

Reported by @jfialli

[glassfishrobot]

@jfialli said:
Upped priority on this one since it represents not being able
to handle all XML Schema possible values.

[glassfishrobot]

@jfialli said:
To accomodate this request,

• year must be set/get via java.lang.BigInteger.
• second must be set/get via java.lang.BigDecimal.

Following API changes would need to be made:

1. Add XMLGregorianCalendar constructor.
import java.math.BigInteger;
import java.math.BigDecimal;
XMLGregorianCalendar(BigInteger year, int month, int date, int hour, int minute,
BigDecimal second)

2. Add setter/getter via java.lang.Number.

java.lang.Number getField(int field);
void setField(int field, java.lang.Number value);

From implementation point of view, some protected methods of GregorianCalendar
need to be altered to include enhanced data representation of year and seconds.
(ComputeTime() for one.) More research needed to determine how doable or
not this is. Definitely need to evaluate impact that this has on equals method.

Also, XMLGregorianCalendar class javadoc must be updated to state that rounding
down occurs if a year requiring BigInteger and seconds requiring BigDecimal are
accessed via existing Calendar get accessors.

[glassfishrobot]

@jfialli said:
Discussion at jsr222 eg meeting on 10/28/2003

From a verbal description of the proposed API changes, the majority of the
expert group members agreed with the approach. As I mentioned in the
meeting, I have not confirmed that this can be implemented given
the current approach of XMLGregorianCalendar extending GregorianCalendar.
The implementability of this approach needs further investigation.
However, the API changes are necessary to support 100% of the possible
XML data values for xsd gregorian calendar datatypes.

[glassfishrobot]

@jfialli said:
To accomodate request to support XML Schema datatype xsd:dateTime's year
and fractional seconds fields

• the high order portion of the XML Schema year field
  must be set/get via java.lang.BigInteger.
• fractional seconds must be set/get via java.lang.BigDecimal.

Following API changes would need to be made:

1. Add XMLGregorianCalendar constructor.
import java.math.BigInteger;
import java.math.BigDecimal;
XMLGregorianCalendar(BigInteger eon, int year, int month, int date, int hour,
int minute, int second, BigDecimal fractionalSeconds)

2. Add following setter/getter.
Note it is always optional if these fields are set.

// Optional Field is considered an XSD required extension of
// Calendar.MILLISECONDS field.
void setFractionalSeconds(BigDecimal)
BigDecimal getFractionalSeconds()

// optional XMLGregorianCalendar field that represents billion of years.
// accomodates that XML Schema dataTime year can be larger than
// Calendar.YEAR field that is only an int.
// Field is treated as an XSD required extension of Calendar.YEAR field
void setEon(BigInteger);
BigInteger getEon();

// convenience methods.
// return Eon combined with Calendar.YEAR field.
BigInteger getYear();

// @param year represents an xsd:dateTime year.
// Decomposes XSD year into Eon and Calendar.YEAR field.
void setYear(BigInteger year);

[glassfishrobot]

This issue was imported from java.net JIRA JSR222-5