[XERCESJ-1232] Canonical lexical value produced for dateTime and time is incorrect.

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.9.0
• Fix Version/s: 2.9.1
• Component/s: XML Schema 1.0 Datatypes
• Assignee: Michael Glavassevich
• Reporter: Michael Glavassevich
• Created: 06/Mar/07 19:57
• Updated: 25/Aug/07 16:13
• Resolved: 06/Mar/07 20:30

Description

Given "2004-01-21T15:30:00-05:00", Xerces will produce "2004-01-21T20:30:00.0Z" as the canoical lexical value instead of "2004-01-21T20:30:00Z". The latter is the correct form. This bug is causing two test cases (datatypenormalization11 and atatypenormalization12) in the W3C DOM Level 3 Load and Save test suite to fail:

1) http://www.w3.org/2001/DOM-Test-Suite/level3/ls/datatypenormalization11(org.w3c.domts.JUnitTestCaseAdapter)junit.framework.AssertionFailedError: firstValue expected:<2004-01-21T20:30:00Z> but was:<2004-01-21T20:30:00.0Z>
at org.w3c.domts.JUnitTestCaseAdapter.assertEquals(JUnitTestCaseAdapter.java:170)
at org.w3c.domts.DOMTestCase.assertEquals(DOMTestCase.java:459)
at org.w3c.domts.level3.ls.datatypenormalization11.runTest(datatypenormalization11.java:95)
at org.w3c.domts.JUnitTestCaseAdapter.runTest(JUnitTestCaseAdapter.java:41)

2) http://www.w3.org/2001/DOM-Test-Suite/level3/ls/datatypenormalization12(org.w3c.domts.JUnitTestCaseAdapter)junit.framework.AssertionFailedError: firstValue expected:<20:30:00Z> but was:<20:30:00.0Z>
at org.w3c.domts.JUnitTestCaseAdapter.assertEquals(JUnitTestCaseAdapter.java:170)
at org.w3c.domts.DOMTestCase.assertEquals(DOMTestCase.java:459)
at org.w3c.domts.level3.ls.datatypenormalization12.runTest(datatypenormalization12.java:95)
at org.w3c.domts.JUnitTestCaseAdapter.runTest(JUnitTestCaseAdapter.java:41)

If the seconds portion of the dateTime/time is less than 10^-3 the canonical value produced will contain a double written in scientific notation, something like "2004-01-21T20:30:04.92E-4Z". This occurs because we're relying on String.valueOf(double) to construct the seconds portion of the lexical value. This second problem is even more harmful because this value is invalid. Note that we check if the canonical lexical value of a value constraint is allowed in the lexical space, so a default or fixed value like "2004-01-21T15:30:00.000492-05:00" will currently be reported as invalid.