Re: Less is more

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