Re: OT: Re: Less is more
Paul Smith <[email protected]> Tue, 04 May 2004 09:31:25 +0100
| Newsgroups | gmane.mail.ng |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] http://www.pscs.co.uk/