[This local archive copy mirrored from the canonical site: http://www.docuverse.com/xlf/ATimestampProposalforXLF.htm; links may not have complete integrity, so use the canonical document at this URL if possible.]
From: Rob McDougall
Sent: Wednesday, August 12, 1998 5:48 PM
Cc: Gavin McKenzie
Subject: RE: A Timestamp Proposal for XLF
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 McDougall Phone: (613)751-4800 ext.5232
JetForm Corporation Fax: (613)751-4864
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.
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.
The following changes occurred to the previous version of this document, thus producing this revision:
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:
Dates must be expressed in any of the following forms:
where the components of the date are defined as:
Time must be expressed in any of the following forms:
where the components of the time are defined as:
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.
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.
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.
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.