In message <Pine.SOL.3.95.970128101451.29431P-120000@eleanor.innosoft.com>, Chris Newman wrote:
ftp://ds.internic.net/internet-drafts/draft-newman-datetime-01.txt
6.8. Examples Here are some examples of Local Date/Time Format: 1999-12-31T23:59:59 America/New_York -05:00 This represents a time one (or two if there's a leap second) second before the year 2000 in the timezone used in New York City in North America (currently U.S. Eastern Time). The offset-hint is the number to add to the local time to get an estimate UTC for that date, so this will probably be equivalent to 2000-01-01T04:59:59Z. Thanks for the new draft. Here are again some comments on it from me: 1) Format If it is really necessary to include a registered time zone algorithm identifier, then I would prefer to see it appended to the ISO 8601 string as in 1999-12-31T23:59:59-05:00/America/New_York If you allow to insert a fields between the time and offset (which is not supported by ISO 8601) and insert spaces into the format, then this is a serious deviation from ISO 8601 and you could also allow the replacement of the "T" by a space as well ... 2) Logic errors in above example Leap seconds are always inserted before midnight UTC, so 23:59:59 is exactly one second before the start of the year 2000 in New York, and not possibly two seconds (the potential leap second on this day in New York would be 1999-12-31 18:59:60-05). "The offset hint is the number to SUBTRACT FROM the local time to get ..." not "add to". There are still lots of typos that require very careful proofreading. 3) Rounding of timestamps: I have one additional suggestion: The spec should mention that if time is known to the system with a higher precision than displayed, then the displayed time should be truncated and NOT rounded. I know software that displays minute precision (e.g. PGP) and adds 30 s before tuncating in order to round to the nearest full minute. I consider this time rounding to be highly counter-intuitive, as users of digital watches expect the display to flip over at the start of the minute or second, and not half a minute or second earlier due to rounding. In order words, the time 23:59:59 should be displayed during any point t in time with 23:59:59.000 <= t < 24:00:00.000, in order to ensure consistency with the common digital clock semantics (ISO 8601 is unfortunately silent about this). 4) Time zone registry The suggested template for a time zone registration request should contain a formal notation for the time zone algorithm. Candidates are the zic and the POSIX TZ formats, with the former one being much more flexible. So far, on the tz list, suggested changes have been communicated for review in the form of diff patches to the tz database zic sources, which eliminates many possible missunderstandings that are very like to occur in a time zone algorithm communicated in English. The nature of the name space (time zone identified by the English name of the largest populated ares in this zone, etc.) should be specified and a rationale should be given for it (see the tz africa file for Paul's background information about the namespace design). The description of the role and purpose of the IANA time zone registry is a little bit unclear. As I understand it, you want to register a list of location descriptors, that can be used to identify the current time zone in effect at any point in time at this location and at locations that share the same time zone algorithm as the identified location. If this is the case, then in addition to the ISO country code, the registry should contain a reference coordinate that identifies the registered location. Such a coordinate file is already part of the tz package (zone.tab). During the switch from summer time back to winter time, usually one hour occurs twice. Your local format (as now the location identifier and not the offset is authoritative) distinguishes not any more uniquely between these two hours. Suggestion: The European laws that define the time zones there define for localtime timestamps that occur twice to append an A after the first occurence and a B after the second occurence. For example: 02:30A Europe/Paris = 00:30 UTC 02:30B Europe/Paris = 01:30 UTC The A/B technique corresponds essentially to the tm_isdst flag used in the C library for distinguishing between ambiguous localtime timestamps during the switch (if there is one). Something like this might be worth being added to the format. (Yes, ISO 8601 does not provide for it, but ISO 8601 also assumes fixes specified UTC offsets and not location identifiers instead.) Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu