Details
-
Bug
-
Status: Closed
-
Resolution: Fixed
-
2.6.2
-
None
-
None
-
Operating System: Other
Platform: Other
-
27783
Description
When a dateTime or time datatype contains leading zeros in its millisecond
value (ie: 15:30:00.0000123000), all leading zeros in the fractional zeros part
are thrown away (ie: above example would be represented as 15:30:00.123000).
This is because the integer value date[ms] that is appended to the canonical
string representation will not include leading millisecond zeros.
Also, only for dateTime (I dont believe it's stated in the spec or errata for
time), trailing zeros in the millisecond value are prohibited [1] (ie: the
value .00123000 should be represented as .00123)
[1] http://www.w3.org/2001/05/xmlschema-errata#E2-63
Have included a proposed patch that appears to work – not sure if best way to
do things. The proposed patch involves increasing the size of TOTAL_SIZE by 1
to include a field in the date[] to store the number of leading zeros in the
millisecond value (date[leadZeros]). The millisecond value is still parsed
using the parseInt method, and the date[leadZeros] value is obtained during
getTime.
In the dateToString method used by dateTime values, leading millisecond zeros
are appended, followed by the value of date[ms], and trailing zeros in the
millisecond value are chopped off. In the dateToString method used by time
datatypes, leading millisecond zeros are appended followed by the value of date
[ms]