Breton Slivka wrote:
The premise that publishers will pick any old format is merely an assertion with no evidence. Please show us an example somewhere else where this has happened, or perhaps a better argument than merely insisting on the "obvious" truth of it.
I have previously mentioned the example of RFC 822. This standard defined a very specific human-readable date format for use in e- mails, and despite the fact that only a handful of people had to deal with it (i.e. the people writing mail clients, not the people *using* them), it quickly fragmented.
Examples of specific deviations are that the RFC defines years to be two digits, whereas implementors quickly started using four digit years. (Fair enough I suppose as two digit years were a poor choice to begin with. The revised specification RFC 2822 switched to four digit years.) It also used strings like "Mon", "Tue", etc for days and "Jan", "Feb", etc for months. Despite the fact that these exact three letter strings were required by the specification, implementors often localised them. Lastly, although it used +/-NNNN for timezones, it also defined alphabetic codes like "GMT" and so forth for about a dozen commonly used timezones. However, many implementations started using other alphanumeric timezones not defined in the spec.
ISO 8601 is a good, well-defined spec for dates and times, with many existing and interoperable implementations. It is clearly the best choice to standardise on as a date format. However, it's important that we offer publishers the option of hiding the ISO date from their visitors and displaying the date in a different format (perhaps even in a different calendar!) for them.
-- Toby A Inkster <mailto:[EMAIL PROTECTED]> <http://tobyinkster.co.uk> _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
