My comments on draft-newman-datetime-00.txt
Chris.Newman at innosoft.com
Thu Jan 16 18:01:48 UTC 1997
On Thu, 16 Jan 1997, Markus G. Kuhn wrote:
> You argue that it is good standards writing practice to let unprofessional
> implementors get away with not reading the spec? If someone does not look
> at the standard, then he or she deserves not to be called a good software
> engineer. You can't make any protocol standard fully guessable by example.
It's good standards writing practice to do everything possible to help
implementors, however unprofessional or stupid, to get it right. I'll
point out that very few email clients get the rarely used "features" of
RFC 822 correct. One of the reasons I didn't do a profile of RFC 822
dates is because the following is technically legal:
Date: Wed, (nesday) 15(Hi There! \))Jan
1997 12:47 -0800 (PST)
I bet most email clients would choke. Rarely used optional features are
always bad for interoperability. They should either be mandatory or
> So they get punished with bug reports and they don't deserve it better!
> They probably will also not understand the -00:00 or Z and will
> forget to accept the fractional seconds. That's no way to develop any
> quality software system.
Of course, the companies prioritize their bug fixes, and supporting the
few people who use minute offsets falls low on the priority list. Yes
it's bad software practice, but when Microsoft, Netscape, AOL, and every
other big company does it, it's better to try to make the standard more
robust for the cretins who seem to be the majority right now.
> The "T":
> - It simply looks ugly
> - ISO 8601 defines both a syntax for a date field and for a time
> field, and protocol designers do not violate the standard if they
> transmit a date and a time field separated by a space character,
> the normal field separator in many systems. The T was provided
> where for some reason (sortability, atomicity, etc.) you want to
> keep the date and time in one single field on database systems that
> separate fields with spaces. I hope that we can get an explanation
> for the "T" along these lines into the next revision of ISO 8601.
I'm not yet convinced. I'm still concerned that this would simply be
creating yet another date/time format. That's a very bad thing to do when
there are already two existing standards to choose from. I'll concede
that the "T" is ugly. I don't find the idea of "two fields separated by a
space" convincing. We're defining a date-time format, and ISO 8601
includes only one date-time format. I want to do an ISO 8601 profile, not
a new format which is vaguely ISO 8601 compatible.
> The decimal comma:
> - The decimal dot is clearly THE decimal separator dominating in
You have convinced me on this one. I'll update it in the next revision.
> It would be great if we could get the format that Paul Eggert and
> I suggested being mentioned as a named profile in the next revision
> of ISO 8601. Then the RFC would only have tutorial function (repeat the
> definition of the profile and provide some examples, example code,
> and usage guidelines). I'd say, it is time that we get involved in the
> work on the next revision of ISO 8601.
I have no control over ISO 8601, no involvement in ISO, no knowledge of
how someone gets involved in ISO, and no interest expending energy
improving standards that people have to pay to read. Innosoft simply
purchased ISO 8601 when we saw it being blindly referenced in new
More information about the tz