Page History

Example: 3:14 pm on 3 January 2001 in Chicago (6 timezones west of Greenwich, standard time) would be represented as "2001-01-03T15:14:00-06:00". 3.5 seconds after midnight on the morning of July 20th 2001 in Chicago (daylight time) would be represented as "2001-07-20T00:00:03.500-05:00".

partialDate, partialTime and partialDatetime formats are compatible with ISO8601(refer to "Representations other than complete"). They are provided to support transmission of dates in which one or more less significant components are unknown at the time of data capture. For example, for a partialDate value the day of the month may be unknown.

The intervalDatetime format is represented as a pair of partialDatetime values representing the beginning and end of the time interval, a beginning partialDatetime and a durationDatetime, or a durationDatetime and an ending partialDatetime separated by a slash (refer to "Representation of time-interval identified by its start and its end", "Representation of time-interval identified by its start and its duration", and "Representation of time-interval identified by its duration and its end" respectively).

The durationDatetime data format is represented as an ISO 8601 duration (refer to "Representation of time-interval by duration only") . For example, 4 hours and 35 minutes is represented as PT4H35M. In the ODM implementation, carry-over of individual component values and negative durations are supported.

The incompleteDatetime format enables transmission of datetime values where one or more of the components -- not necessarily of lower significance -- is missing. The full set of delimiters is used as for a complete datetime, the missing component(s) are represented by a single dash (refer to "Truncated Representations"). In the ODM implementation, most meaningful partialDatetime forms are also supported. For example, 5 minutes after an unknown hour on the 15th day of an unknown month in 2004 is represented as 2004---15T-:05.

The incompleteDate format enables transmission of date values where one or more of the components -- not necessarily of lower significance -- is missing. The full set of delimiters is used as for a complete date, the missing component(s) are represented by a single dash (refer to "Truncated Representations").
For example, 2001---30 means the 30th of an unknown month in the year 2001, and ----30 means the 30th of an unknown month and unknown year.

The incompleteTime format enables transmission of time values where one or more of the components -- not necessarily of lower significance -- is missing. The full set of delimiters is used as for a complete time, the missing component(s) are represented by a single dash (refer to "Truncated Representations").
For example, -:55:30 means 30 seconds after the 55th minute of an unknown hour, and -:-:30 means 30 seconds after an unknown minute of an unknown hour.

The hexFloat and base64Float data formats are binary types intended for precise exchange of floating-point data in a machine/platform independent manner. The types are based on the IBM Mainframe format used in SAS V5 Transport format -- described in the SAS Technical Support document "TS-140 The Record Layout of a Data set in SAS Transport (XPORT) Format"

Note: Data values transmitted as hexFloat or Base64Float will not be humanly readable in an XML markup or by a standard XML authoring tool. For this reason, the decision to use these types implies that an application will be needed to process data received in this format.

Values for hexFloat and hexBinary data are encoded as character tuples consisting of two hexadecimal digits ([0-9A-F]).

Values for base64Binary data are encoded using the 65 characters of the Base64Alphabet. These include a-z, A-Z, 0-9, +, /, = and the whitespace characters defined in [XML 1.0 (Second Fift Edition)].

The hexBinary and base64Binary datatypes may also be used for exchange of floating point values, but may be subject to platform or application dependencies. Implementers should note that this could result in an inability to determine whether the receiving application has interpreted a value as a string rather than as a float. Encoded values using these datatypes may be exchanged reliably only across similar hardware platforms.

Note: ODM 1.1 allowed a timezone specification of -99:99 to designate "no timezone information." This format is no longer supported.