| |||
prev next Table of Contents Common Elements | |||
3.18 xs:dateTimeMany elements in the Cloud Fax and Notifications API schema are defined using the xs:dateTime format. This format is specifed in the W3C XML Schema language. The following description is from the W3C Recommendation, "XML Schema Part 2: Datatypes Second Edition": The lexical space of dateTime consists of finite-length sequences of characters of the form: '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)? where
For example, 2002-10-10T12:00:00-05:00 (noon on 10 October 2002, Central Daylight Savings Time as well as Eastern Standard Time in the U.S.) is 2002-10-10T17:00:00Z, five hours later than 2002-10-10T12:00:00Z. And from the description of "timezones": Timezones are durations with (integer-valued) hour and minute properties (with the hour magnitude limited to at most 14, and the minute magnitude limited to at most 59, except that if the hour magnitude is 14, the minute value must be 0); they may be both positive or both negative. The lexical representation of a timezone is a string of the form: (('+' | '-') hh ':' mm ) | 'Z' where
The mapping so defined is one-to-one, except that '+00:00', '-00:00', and 'Z' all represent the same zero-length duration timezone, UTC; 'Z' is its canonical representation. So date/time values in Cloud Fax and Notifications API input and output will look something like this:
The "timezone" as used in this format is not quite the same as the common meaning of the term, which entails some geographic association and additional rules like Daylight Savings Time. Consequently, the dateTime values are basically used to specify a point in time, and may use any appropriate "timezone" value as long as it turns out to represent the right time. Most uses of xs:dateTime in the Cloud Fax and Notifications API are intended to specify an absolute point in time, so the timezone is significant, but is not guaranteed to have any particular value. The "Z" format is likely to be the most common, but should not be relied upon - client programs must correctly interpret xs:dateTime values for any desired locale. There are a couple of uses that use an xs:dateTime value to specify a local clock time (as for the RecipientTimezoneOption), and for these the timezone is either ignored or omitted. | |||
| |||
prev next Table of Contents Common Elements | |||
|