The precision of its specification is not the main issue. The main
issue is that it's a compromise between machine-readable and
human-readable
I agree with that statement- but it's a direct result of the broader
design choice to make email mesages be both machine-readable and
human-readable. Changing the date format without revisiting the
larger
choice is probably wasted effort.
If you look at MIME and/or HTML mail then the idea that mail is
readable by humans without a mail client is mostly theorectical today.
no argument there. I probably prefer a "binary" (i.e. not intended to
be human readable on-the-wire) format myself, though the ability to
"type in" messages on the fly for debugging purposes should not be
underestimated.
Not so. The amount of work in decoding an integer (say a UNIX-style
time_t) to a date is approximately equal to the amount of work in
parsing a RFC822 style date, and it's at least as easy to botch
up the decoder as to botch the RFC 822 date parser.
Not having written any, I have a hard time believing this. Even
something as trivial as finding the text between the whitespace is a
huge pain without text parsing libaries.
And manipulating dates is also a huge pain without libraries to do that.
actually I've written dozens of mail tools and never used a text
parsing library. eventually I wrote my own generic lexical analyzer for
header fields (you pass it a string and a set of flags telling it
things like whether comments and quoted-strings are significant and
what characters are 'special', and it returns a list of lexemes) but
that routine is only about 100 lines of code.
The amount of
work in encoding an integer date from yyyy/mm/dd/hh/mm/ss form
is more than the amount of work in encoding that same quantity
in RFC 822 format - and it's harder to get that encoder right.
But I think most OS builders have gotten it right by now.
probably so, thanks to POSIX. mktime() hasn't been widely available
until recently.
About timezones: note that these aren't inherently interesting: I
don't care which timezone is configure on a server that happened to be
on the path for a message. The reason the timezone (or rather: the
local time for the sender) is interesting in mail is because it can be
interesting to be able to see whether someone wrote something during
business hours or late at night or whatever. Apart from this we only
need UTC.
so have timezones for Date and require UTC for the equivalent of
Received? offhand that seems reasonable.