From: Rob McDougall
Sent: Wednesday, August 12, 1998 5:48 PM
To: 'donpark@quake.net'
Cc: Gavin McKenzie
Subject: RE: A Timestamp Proposal for XLF

Don,

Sorry about the HTML formatting, but I thought it best to try and keep the formatting reasonably intact. I hope your email reader can handle it.

I believe you've been talking to a colleague of mine (Gavin McKenzie) about XML Packaging formats. We've looked into Date & Time as well. This is what we came up with. These rules are very similar to the ones you are proposing, but allow for a little more flexibility. For example, we allow a user to specify just a year in a date if they wish. This may be useful for log file rollups and summary reports.

Feel free to use or disregard our ideas as you see fit. I hope this helps,

Rob

=======================================================
Rob McDougall            Phone: (613)751-4800 ext.5232
JetForm Corporation      Fax:    (613)751-4864
http://www.jetform.com   mailto:rmcdouga@jetform.com
=======================================================

Abstract

This document is a specification and a profile of [ISO8601], the International Standard for the representation of dates and times. [ISO8601] describes a large number of date/time formats. To reduce the scope for error and the complexity of software, it is useful to restrict the supported formats to a small number. This profile defines a number of date/time formats, that should satisfy most requirements.

Introduction

This document originally was an adaptation of the W3C Note "Date and Time Formats" [DATETIME], but has since diverged to a point that it should now be viewed as simply a profile of [ISO8601].

The International Standard for the representation of dates and times is ISO 8601. Its full reference number is ISO 8601 : 1988 (E), and its title is "Data elements and interchange formats - Information interchange - Representation of dates and times". A very useful discussion of ISO 8601 has been written by Markus Kuhn.

ISO 8601 describes a large number of date/time formats, which would require complex software to process -- we have attempted to simplify where possible.

A particular problem with ISO 8601 is that it allows the century to be omitted from years -- this is clearly not acceptable. Hence this specification requires that years must be comprised of four digits in all cases.

This specification does not imply any presentation behaviours (such as display or print formatting) of dates or times -- it only specifies how the date/time data content should be represented within data content.

Revision Changes

The following changes occurred to the previous version of this document, thus producing this revision:

Watered down some of the hyperbole around the value of providing timezone information.

Formats

The following sections present the acceptable formats for date and times, with accompanying notes and examples.

The syntax specification of a particular format of date or time is described in a format where:

Italicized letters denote placeholders that will be defined as referring to a component of date or time.
For instance, ccyy will be defined as "cc -- a two digit century, yy -- a two digit year"
Square brackets enclose an optional portion of the format.
All other characters should be assumed to be literal characters.

Date

Dates must be expressed in any of the following forms:

ccyy[mm[dd]] -- examples:
19970716 199707 1997
ccyy[-mm[-dd]] -- examples:
1997-07-16 1997-07 1997

where the components of the date are defined as:

cc -- two digit century
yy -- two digit year
mm -- two digit month (01 (January) through 12)
dd -- two digit day (01 through 31)

Notes:

All components must be zero padded to two digits.
The only punctuation character that is acceptable between date components is the hyphen character u002d.
Not all of these formats constitute a date to the precision of an actual day, hence it is up to the application to determine whether "1997-07" is an acceptable date, i.e. is the application looking for a particular day, in which case 1997-07 is not precise enough because it doesn't specify a day.

Time

Time must be expressed in any of the following forms:

hh[mm[ss[.ffff][Z]]]
hh[mm[ss[.ffff][+hh[mm]]]]
hh[mm[ss[.ffff][-hh[mm]]]]
hh[mm[ss[.ffff][+hh]]]
hh[mm[ss[.ffff][-hh]]]
Examples:
202045.4321Z 192045.4321-0100 192045.4321-01 192045.4321 192045 1920 19
hh[:mm[:ss[.ffff][Z]]]
hh[:mm[:ss[.ffff][+hh[:mm]]]]
hh[:mm[:ss[.ffff][-hh[:mm]]]]
hh[:mm[:ss[.ffff][+hh]]]
hh[:mm[:ss[.ffff][-hh]]]
Examples:
20:20:45.4321Z 19:20:45.4321-01:00 19:20:45.4321-01 19:20:45.4321 19:20:45 19:20 19

where the components of the time are defined as:

hh -- two digit hour (00 (midnight) through 23) (am/pm NOT allowed)
mm -- two digit minute (00 through 59)
ss -- two digit second (00 through 59)
ffff -- any number of digits specifying fractional seconds always preceded by a dot (Unicode character u002e). This specification does not wholly specify how many digits may be used to represent the decimal fraction of a second, but does require that a minimum of 4 digits be supported.
a timezone designator which:
- if omitted states a local time with an unknown timezone. This may contravene the [ISO8601] specification, I'm not sure. Unfortunately even if it does contravene the specification it has been deemed a requirement that we allow you to omit the timezone information. It should be noted that doing so will cause your time data value to be useless to applications that operate within other timezones and wish to perform time-based calculations. Therefore, you are strongly encouraged to write software that produces time data with a timezone designator.
- if 'Z' (Unicode character u005a) states [UTC] ('zero meridian', or 'Zulu Time')
- if an offset of plus or minus an hour/minutes states that the offset can be added to the time to indicate that the local time zone is hh hours and mm minutes ahead or behind [UTC]. The plus or minus sign must be included.

Note:

The hour, minute, and second components must be zero padded to two digits.
The only punctuation character that is acceptable between the hours, minutes, and seconds components is the colon character (Unicode character u003a).

Date-Time

A date and time specified according to the previous sections can be combined into a single date-time value by concatenating the values together, separated by a 'T' (Unicode character u0054). The requirement for the 'T' character is a particularly annoying and controversial part of the [ISO8601] specification; but that's the way it is. If the 'T' is deemed confusing to human users, then the software should take care of transforming the 'T' in and out of existence during read/writes of data.

Example:

1997-07-16T20:20:45.4321Z

Justification

Several early reviewers of this specification were uneasy about allowing the user to omit a time zone from a time in a data file. The following example illustrates why it is necessary to allow for this.

Example Scenario

A large corporation has offices all across North America spanning 3 time zones. The corporation's main database is stored in a city (say Toronto) in the Eastern time zone. As transactions are entered in each location, using a custom application and are stored in a common database table in the main database (in Toronto). The transactions include a "time entered", but no time zone info.

The transactions are extracted from the database (again using a custom app) and used create an XLF file. Let's say that, in this case, the extracting process does not have enough information to determine the correct time zone. Clearly, forcing the user to specify a time zone on the data is incorrect. Not all data is from the same time zone. This is why time zone information is optional (though highly recommended).

To carry on with this example, as the transactions pass through the workflow these times are compared with each other and with other times that also don't have a time zone (but the system is designed such that no two times that are compared are ever from different time zones). The data is saved and sent onwards after each workflow step. Clearly, we must maintain the data's lack of a time zone within an XLF application.

Handling Calculations

If at some point a time without a time zone is compared with one that does have a time zone, we have a problem. The best compromise seems to be to tack on the local time zone at this point. If the user wants something else, then they will have to construct a time with the correct time zone from the under-specified time. This is analogous to mixing calculations with integers and floating point numbers. If your calculations deal strictly with integers, then the result is an integer, but the moment you insert a float into the calculation, the result is a float. The same applies to times without time zones. Calculations involving times without time zones generate a result without a time zone. Calculations that mix data with and without time zones generate a time with a time zone. When a time is promoted to contain a time zone, the local time zone is used.