On 28-apr-04, at 22:59, Keith Moore wrote:
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.
I think there is middle ground between having a binary-only or a
no-binary format. Since mail must both support readable text and opaque
binary data neither extreme is attractive. I think it makes a lot of
sense to, in addition to those fields that are binary by their nature,
make some common fields binary if this has advantages. The date is a
very good example. While having the date in binary means that even the
lowest of low-level mail reading software must be able to decode it,
writing such an application is trivial, and writing one that can
actually do something useful with the dates it encounters in mail is
just as trivial, which certainly isn't the case for the current format,
and I expect this to be difficult for improved text-based formats too.
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.
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.
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.