1. Xerces2-J
  2. XERCESJ-919

Canonical representation of dateTime and time has incorrect millisecond value


    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 2.6.2
    • Fix Version/s: None
    • Labels:
    • Environment:
      Operating System: Other
      Platform: Other


      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

      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


        No work has yet been logged on this issue.


          • Assignee:
            Sandy Gao
            Naela Nissar
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: