Date and Time Formats

The following formats are used throughout Universal API schema unless exceptions are noted.

General Formats

Universal API adheres to the ISO-standard specification of date and time supported by the W3C in the xs:dateTime format:
yyyy-mm-ddThh:mm:ss.s+zzzzzz

Where:

• yyyy is the year

• mm (first) is the month

• dd is the day

• T is a separator indicating that time-of-day follows

• hh is the hour on a 24-hour clock

• mm (second) is the minute

• ss is whole seconds

• s (optional) is the fractional second

• zzzzzz is the time zone

Note: See http://www.w3.org/TR/xmlschema-2/#dateTime for the full lexical description of the dateTime format.

The following examples indicate the format:

Date and Time	Description
2009-10-10T12:00:00-05:00	Noon on 10 October 2009, Central Daylight Savings Time or Eastern Standard Time in the U.S.

Note: Universal API does not support Zulu Time (GMT) formats, such as 2009-10-10T12:00:00Z. However, some providers may return Zulu time.

System Dates and Times

Any system-generated times are specified with the xs:dateTime type. This format is returned for all dates and times except:

• Flight times/

• Booking creation and modification times.

• Ticketing time limits.

Currently, data is returned in Greenwich Mean Time (GMT). For example:

<PNR Version="1" CreateDate="2009-05-11T13:13:02.802" ModifiedDate="2009-05-12T07:17:51.984">

Flight Dates and Times

Flight-related dates and times follow the standard practice of being in represented as Airport Local Time at the place of arrival or departure. The correct time zone offset is also included in this field.

For example:

<AirSegment Key="1" Group="0" Carrier="AS" FlightNumber="563" Origin="SFO" Destination="SEA"

DepartureTime="2009-06-02T09:00:00.000-07:00"

ArrivalTime="2009-06-02T11:10:00.000-07:00"

ClassOfService="V" ETicketability="Yes" Status="HK"\>

However, most of the fields in the requests that accept date/time data is defined as a xs:string type rather than a xs:dateTime type. This is due to the number of XML marshalling tools that process these field types. Typically, these tools attempt to shift the time from the specified time zone offset to the local time zone offset.

For example, a segment with a Pacific Standard Time airport, processed by an Atlanta-based system, in Eastern Standard Time:

Origin="SFO" DepartureTime="2009-06-02T09:00:00.000-07:00"

is converted to:

Origin="SFO" DepartureTime="2009-06-02T11:00:00.000-04:00"

Although this conversion is technically correct, and both represent the same time, it does not properly represent Airport Local Time. With the fields represented as xs:string, the client application processes and converts the time according to its protocols, and makes or does not make adjustments. There is no automatic conversion that has to be undone.

Although this usage implies that the system expects the time zone offset value to be sent in with all date/time fields, this is not the case. It is assumed that the data returned in the search requests (which includes the offset values) would simply be returned during pricing or booking requests. However, this has not been the desired situation for the various client applications.

As a result, we maintain a database to link Airports and Time Zones to determine the offset value in the event it was not sent in. But, if the Zulu format is received, we will assume GMT time and make the appropriate adjustments. So, it is recommended to send in either the complete or partial date/time format, and not the Zulu format.

Preferred:

2009-06-01T10:00:00.000-05:00

2009-06-01T10:00:00.000

Not recommended:

2009-06-01T15:00:00.000Z