draft-newman-datetime-01.txt

[Chris Newman]

Thanks for the helpful comments!

On Tue, 28 Jan 1997, Markus G. Kuhn wrote:
> 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 ...

I do believe we need a new format for future times where the timezone name
is authoratative, it could potentially be split into a separate document
if that was thought to be helpful. The primary need for this is to specify
future and recurring events for the calendaring and scheduling work.  The
zone offset hint in the local format has very different semantics from
the zone offset in ISO 8601, so I felt it was important to use a different
syntax for it.  The basic idea was to take the ISO 8601 local time format,
append the timezone name to fully qualify it, then the optional offset
hint.  As far as I'm concerned, any reasonable syntax for the stuff after
the ISO 8601 local time is fair game.

> 2) Logic errors in above example

Thanks.  I'll fix those in the next draft.

> 3) Rounding of timestamps:

Good idea.  I'll add it in the next draft.

> 4) Time zone registry

What I wanted to avoid was having the IETF/IANA take over the work 
currently being done by the timezone mailing list to maintain the timezone
archives.  What I wanted to do was to give a "standards blessing" to the
names used in the timezone archive, without pretending that the IANA (or
anyone on the Internet) can keep a set of zone rules which have
standards-level authority.

> 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.

The POSIX format is obviously inadequate.  But I really don't want IANA to
register the zone rules -- I just want a registry of the zone names.  The
zone rules can be found two ways: through informal channels on the
Internet, or by contacting the appropriate government.  Frankly, I think
this list is doing a superb job of maintaining zone rule archives and
have no interest in competing with it or mucking with the current
functional process.

> 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).

Good idea.  I didn't notice that before.  I will suggest one change to
Paul's rules -- namely that "-" be used to represent spaces in
future names rather than "_".  It turns out that "_" causes problems in a
number of contexts (some non-english countries, underlined words, terminal 
screen with blinking underscore cursor, some printing contexts).

> The description of the role and purpose of the IANA time zone registry is
> a little bit unclear.

Yeah.  I'll work on it.

> the case, then in addition to the ISO country code, the registry should
> contain a reference coordinate that identifies the registered location.

That does make sense.  Agreed.

> 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.

True.  Summer time is really a pain.  Your suggestion is quite reasonable
-- I'll add it to the next draft.