draft-newman-datetime-01.txt

[Markus G. Kuhn]

In message <Pine.SOL.3.95.970128101451.29431P-120000 at 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 at cs.purdue.edu