mail-ng
[Top] [All Lists]

Re: Less is more

2004-04-27 13:40:38

On Wed, 28 Apr 2004 04:40, Keith Moore wrote:
The RFC 822 date format is specified to a reasonable degree of precision.

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, a 
compromise which I have rarely found to be a happy one.

The grammar and corresponding parser for an RFC822 date is moderately complex, 
compared to, say, two integers which represent the time and the timezone, 
although the latter will not be at all meaningful to the average man in the 
street. Most programming languages are trivially capable of converting 
integers to and from strings, whereas an RFC822 date requires a modest amount 
of work to generate and/or parse. The more work is involved, the greater the 
scope for error in implementation (and ambiguity in specification).

I'm for date formats which are primarily machine-readable, since dates should 
be expressed in a localised form for the user anyhow. RFC822 dates are 
anglo-centric (they use English month names), and a good client ought to 
convert them back to a numeric time format, then forward again into the 
localised date and time string.

This argument generalises to things other than dates. There's a trade-off with 
ease of debugging in many cases, but we should tend towards machine-readable 
data formats where compromise is necessary.

(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)

Funny -- I've always considered this particular piece of data to be mostly a 
nuisance from an implementer's perspective. Do you show dates in the 
recipient's time zone, or the time zones of the various senders? Not to 
mention that back-converting a timezone to UTC for localisation purposes 
increases the complexity of your time-related function requirements.

My suggestion for a good date format is *one number* which represents the date 
as an offset of time units from a given epoch (although I'm being 
deliberately non-specific about the time units and the epoch, and whether the 
number is integer or floating point). A time zone is a separate entity in 
most cases, descriptive of a *place* more than a time. (It's an offset to 
convert universal time into time-of-day for that place, to be precise.)


<Prev in Thread] Current Thread [Next in Thread>