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