but please
don't let us settle for anything like the RFC822 Date-format,
This is a potentially instructive example.
The RFC 822 date format is specified to a reasonable degree of precision.
There were only really a few botches:
- it got US military timezones wrong, but nobody ever uses these anyway
- it specified 2 digit years, but RFC 1123 extended these to four digits
well in advance of y2k
- the alphabetic timezone names it used were reasonably well-defined,
but the fact that these were US-centric tempted people to add their
own timezone names which were less well-defined and sometimes ambiguous.
again, numeric timezone offsets have been encouraged for several years.
- day of the week can be inconsistent with the date - this is either a bug
or a feature (redundancy check) depending on how you look at it
After ~23 years of widespread use, that's really not bad at all.
(one thing that wasn't botched was the use of timezones - it really does
help to know the sender's local time when a message was sent)
Now we all recognize that implementations vary considerably from this
specification. But I don't think the problem was lack of clarity in the
specification. And given the overall decision to represent email as a
text file, it's hard to see how RFC 822's date specification is any worse
than any other date specification that might have been used.
Looking at the malformed date strings I can find in mail messages, I
am guessing that there are two reasons for the fact that malformed
dates are so common:
- Some platforms don't provide any kind of timezone offset,
so the programmer either has to guess, or supply a date without a
timezone, or require that the user configure one.
- Some programmers are just too lazy to read the specifications,
so they slap whatever date string they can find in the field.
- Sometimes a programmer tries to get it right and just botches it,
usually by failing to test for fairly obvious boundary conditions
(like the dates with years in the 20101 range..)
I'm not sure what mail-ng could do to solve those problems while still
retaining a useful date field.
--
Regime change 2004 - better late than never.