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