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 circles.
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. and 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@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@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: <ftp://ds.internic.net/internet-drafts/draft-fielding-url-syntax-03.txt>) no longer recommends this. Personally, I think it's ugly and modern free-text URL recognizers find URLs in unadorned <> just fine.