Chris Newman Chris.Newman at innosoft.com
Thu Jan 30 20:27:58 UTC 1997

The majority of what I didn't comment on, I agree with and will fix.

On Wed, 29 Jan 1997, Paul Eggert wrote:
> (where the bracketed items are optional), require the UTC offset instead:
> 	1996-10-27T02:30:00 Europe/Paris +02:00
> 	1996-10-27T02:30:00 Europe/Paris +01:00
> This counterproposal simplifies the notation and removes options,
> which is a stated goal of the draft.

The problem with making the UTC offset hint mandatory in all cases is that
it is quite possible that a computer will know the standard timezone name,
but not be able to compute future UTC offsets.  Since the time is
unambiguous (except during offset shift times), I believe it's reasonable
and useful to allow the UTC offset hint to be omitted by such computers.
Asia/Tel_Aviv is another case where omitting the UTC offset hint for
future dates might be a good idea (especially near the end of March).

> The only problem I see here is that section 6.3 of the draft
> recommends hyphen over underscore for future names, which disagrees
> with current practice.  The current database contains just 3 names
> with hyphen, as opposed to 44 names with underscore, so the
> recommendation in 6.3 to avoid underscore would lead to confusing
> inconsistencies as new names are added.  Also, in the current tz
> database, hyphen represents itself (e.g. "Port-au-Prince") and
> underscore represents space (e.g. "New_York"), so the recommendation
> in 6.3 to avoid underscore would cause minor loss of information.  In
> practice, underscore should not be a problem, as software can
> transliterate it to a space before display if underscore has
> undesirable behavior in a particular application.

I agree with your argument, but I have a lot of expertise in IETF history,
and I expect opposition to using "_".  For the next draft, I'll try to
include a similar explaination and see if I can get away with it in IETF

> Unfortunately, I don't have a copy of ISO 8601 to quote chapter and
> verse on this.  I hope that someone else with access to ISO 8601 can comment.

I'll confirm that:
A) ISO 8601 permits "T" to be omitted by mutual agreement.
B) ISO 8601 does not permit " " to be used anywhere in the format.

As I posted earlier, I think the right solution is to require the "T" for
Internet protocol interoperability, but suggest that subtituting a " " for
the "T" is reasonable when displaying to a human.

> ``MUST'' is too strong here, since the draft is talking about how a
> host should handle text that does not conform to the protocol.  At
> best this section should say ``should'' instead of ``MUST''.

I mention "Email Date/Time Format", which is the format defined by RFC
822 and updated by RFC 1123.  Two digit years are legal (but not
recommended) in that format.  I'll add a clarification that two digit
years are not legal in the Internet Date/Time Format.

> The last subsection (about dates like `:0-12-31') is a bit bizarre.
> (Will the draft eventually include similar recommendations for EBCDIC?
> After all, mainframes have the most problems with 4-digit years....)
> I would remove it.

I'll consider removing it, or restructuring it a bit.  I like to warn
people of problems they're likely to encounter.  I suspect the number of
EBCDIC generators remaining on the Internet is not signficiant enough to
merit this type of warning.

> 4.3.  The difference between +00:00, -00:00, and Z is not explained well.
> I would add words to the following effect.
> 	The time-offsets "+00:00", "-00:00", and "Z" all specify UTC
> 	but they have different semantic interpretations, as follows:
> 		"+00:00" means local time is equal to UTC.
> 		"-00:00" means local time is unknown.
> 		"Z"      means local time is irrelevant.
> However, I don't see the need for "-00:00"; "Z" suffices for both
> unknown and irrelevant local times.  I would remove "-00:00".

Email Date/Time format recommends that only numeric zones be used.
The "-00:00" idea came from discussions about that format on the DRUMS
(Detailed Revision and Update of Messaging Standards) mailing list and
the idea was popular.  I'll give another try at clarifying the wording.

> 6.3.  No current implementations that I know of support
> case-insensitive matching for time zone rule names; they are all
> case-sensitive.  This requirement is unnecessary and should be removed
> (or at least should be changed from MUST to SHOULD).

Case-insensitivity is very popular in the IETF.  On the other hand, if the
"T" and "Z" are case-sensitive, then the zone rules probably should be as
well for consistancy.  I'll try changing this.

> 6.4.  I suggest that IANA coordinate with tz at elsie.nci.nih.gov on time
> zone rule name registry.  I suggest that XXX be `elsie.nci.nih.gov',
> but you'll need help with ado at elsie.nci.nih.gov to set this up.

That's a good idea.  The only concern I have is that since RFC's are
permanent publications, it's best to try to find a host name which is
expected to be permanently available.  Current practice in the IETF is to
use "ietf.org" for XXX.  I will try to make it clear that best efforts
will be made to coordinate the formal name registry with the informal
name/rules registry maintained by the tz list.

> 6.5.  I'll volunteer to review time zone rule names, if that helps.

I'd appreciate that.

> 6.7.  I agree with Markus that it's odd to put the zone-name smack in
> the middle of the ISO 8601 time stamp; it'd be better to put it after.
> This is more consistent and will make it easier to write date parsers.

As I explained to Markus, I think there is an important distinction
between a UTC offset (which is authoratative) and an offset hint (which
may not be correct).  I'm quite reluctant to use the same syntax for both.

> Also, why is this format constrained to future dates?
> Please explain why this constraint is needed.

There isn't any current or proposed Internet Protocol which uses
historical dates.  A list of all historical time zones is much larger and
much more difficult to implement on small devices (like a calendaring
PDA).  I like to solve the smallest problem that needs to be solved when
it simplifies the result.  Present and near-past dates can be represented
using ISO 8601 unambiguously and it's a far simpler format to process.  As
far as I'm concerned, a format using time zone rule names is a necessary
evil that should be avoided whenever possible.

> The document sometimes breaks lines improperly (e.g. `1996-12-
> 20T00:39:57Z').

Anyone know how to fix this using troff?

> 6.2 (and other sections).  Use <URL:...> syntax as per RFC 1738.

Since the <URL:...> syntax is not common practice, the next revision of
the URL specification (currently:
no longer recommends this.  Personally, I think it's ugly and modern
free-text URL recognizers find URLs in unadorned <> just fine.

More information about the tz mailing list