Re: OT: Re: Less is more

[Paul Smith <paullocal@xxxxxxxxxx>]

At 16:24 03/05/2004, Brett Watson wrote:

> > Keith Moore writes:
> > > But if you look at the kinds of malformed dates that are out there,
> > > most are not malformed because the programmer tried to use some legal
> > > variant of the date syntax and failed to get it right - they're
> > > malformed because the programmer failed to even try to get it right.
>
> To which Arnt Gulbrandsen wrote:
> > True. But IMO, if the syntax were simple, strict and understandable to
> > the average programmer, this probably wouldn't happen.
>
> I'm not so sure, Arnt. I get the feeling with many mail implementations that
> the implementors failed to appreciate that RFC822 was actually meant to be a
> strict grammar at all. Perhaps the human-readability of it lends the
> impression that it's *only* meant to be human readable.

I will admit, that's what I did originally (7 or 8 years ago). I soon 
realised we'd got it wrong, but that's because we listen to user feedback 
and assume that almost anything is our fault until we prove otherwise 
(unlike some other people who presume the other way :-( )

In that case the human readability WAS the problem - it looked like a daft 
format for a date/time field to be in, if it was intended to be computer 
readable... I presume it was that way because back in those days most email 
clients would have just displayed the date field as-is - nowadays most seem 
to want to parse it, eg for timezone translation, internationalisation etc.

IMHO, a 'simple' 'yyyymmddThhmmss(+|-)tz' field would be better
Date: 20040504T092214+0100

It's human readable enough to be easy for problem diagnosis, but it's not 
so human readable that any reasonable programmer would assume that that's 
its prime purpose - it looks to be in a computer friendly format.

Yes, I can see there could be problems (eg people transposing month/date 
fields or even year/month/date fields, getting the timezone 'sense' wrong 
or putting in invalid dates) - but are those worse than we have now?

Going for an 'epoch' system (eg seconds since 17th March 1973 or whatever) 
is (IMHO) more problematic since you start getting affected by leap-seconds 
(or at least having to worry about how not to be affected by them) - it's 
also less human readable.


Paul				VPOP3 - Internet Email Server/Gateway
support@xxxxxxxxxx			http://www.pscs.co.uk/