Nobody has mentioned the international date-time standard ISO 8601. This is the basis of RFC 3339, the basis for date-times in SQL, and the basis for dates in the iCal calendar standard and thereby in the microformat standard for date-time.

I can not agree with your statement

an RFC 2822 date like “Tue, 12 Jun 2007 08:53:21 +1000″ is much nicer and easier to read for a human than an RFC 3339 formatted date like “2007-06-12T08:53:21+10:00″

It is perhaps a tiny bit nicer and easier to read for an English speaker, only because of its familiarity. The time portion in each case is about the same; the ISO 8601 date format YYYY-MM-DD is easy to understand even for those who never saw it before, and it is standard usage in Asia. Personally, I have been using this date format since 1974.

Versailles, Tue 19 Jun 2007 17:19:50 +0200

To make it quite clear, I am not trying to pull this down as a solution to the Author’s problem. However when I first started to read the article, I thought that it might offer a solution to a problem of mine, but I am still not convinced that this is a universal solution.

I am afraid that your argument is also flawed - this date format may be used in 95% of emails (or whatever the percentage actually is) but it is never read by a human. To me, +1000 is very nearly as ambiguous as using a time zone abbreviation, as it is not clear whether the 10 hours should be added or subtracted to the time as written.

Similarly, my point about the date format being ambiguous again applies to Human use. By including both the day name and the date number, the possibility of ambiguity is introduced if the two do not match, which is very likely if it is edited by hand.

Still don’t get what your last para means - what is the relation between SMTP and HTTP ?

This is the ONLY official (and unambiguous) way to state that the TOG (Time Offset over GMT) is + 10 hour 0 minute (I recall that RFC2822 states to use TOG, not “time zone”). Since used in headers of 95% of the email messages on earth, it is quickly and unambiguously understood by most people anywhere on the planet; as Paul Annesley said on Tue 12 June 8:57: « the RFC 2822 format is non-ambiguous ». Please see details in PST and PDT; TZ and TOG; UTC and GMT; Internet Date & Time; PHP date. I add that a date like “1/2/3″ (or “01/02/03″) is read:

- by an American, as (Thu) 2 Jan 2003
- by an European, as (Sat) 1 Feb 2003
- by a Newzealander, as (Sat) 3 Feb 2001

omnicity said Wed 13 June 19:09: « …relying on a single portion of an otherwise un-related RFC is strange (what has SMTP got to do with HTTP ?) »

RFC2822 is titled “Internet Message Format”, its chap 3.3 is “Date and Time Specification”, and is applied by 95% in the ~200 countries on earth, hence looks IMO quite “related” in this discussion titled “Simple Date and Time Localization With JavaScript”.

Versailles, Tue 19 Jun 2007 11:42:05 +0200

Again, doesn’t it make more sense to use a truly unambiguous machine-only format that is hidden from the user, coupled with a nicely formatted human-friendly, visible date?

If our requirements change in the future, for example if we provide our content in a language other than English, then we could choose another suitable format. We have the flexibility of using any format which JavaScript Date understands, without having to change any of our JavaScript code.

I’m perfectly happy to borrow a suitable date format from an unrelated RFC, rather than making up a non-standard format or using a less suitable one. And given the flexibility we have, it’s no drama if our first choice doesn’t turn out to be the best.

My point was firstly that relying on a single portion of an otherwise un-related RFC is strange (what has SMTP got to do with HTTP ?)
Secondly, the date is not fully readable, fully internationalised, nor much else. Surely it makes more sense to do this the other way around?