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