[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.