Markus G. Kuhn
kuhn at cs.purdue.edu
Tue Jan 28 22:30:17 UTC 1997
In message <Pine.SOL.3.95.970128101451.29431P-120000 at eleanor.innosoft.com>,
Chris Newman wrote:
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:
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
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
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 G. Kuhn, Computer Science grad student, Purdue
University, Indiana, USA -- email: kuhn at cs.purdue.edu
More information about the tz