Start sending dates the right way (aka The ISO8601 101)

ISO 8601 defines a number of lesser known features. For example, it allows for not only fractional seconds (12:34:56.78) but also fractional hours (12.3) and minutes (12:34.93). There is a special notation for the midnight of certain day (24:00:00 or 24:00), and obviously another for a positive leap second (08:59:60 etc.). There are three ways to write a date: 2012-05-21, 2012-W21-1 and 2012-142. Intervals can be specified in terms of start and end, start and duration, duration and end, just a duration (i.e. no context). There are also recurring intervals which can be bounded in the number of recurrences or not. And so on and on and on.<p>That said, ISO 8601 tries to cover most cases for date/time representation. Implementing every bit of ISO 8601 is not desirable of course, but it is certainly worth looking at.

<i>... with ISO8601 intervals you can express this as a string format, rather than using something ghastly like seconds or milliseconds:</i><p><pre><code> 'P6Y4M4DT3H45M15S' </code></pre> To me, that is absolutely no less "ghastly" as just saying the period is 3600 seconds (or whatever...)

Very good advice! ISO8601 is a perfect tradeoff between the machine readable Unix timestamp, and the human readable mess used in http.<p>The only thing libraries often get wrong is that the timestamp should always be present and default to 'Z'. It's pretty rare to want timestamps in local time except during debugging, but that's often the default. It catches a lot of people out.

RFC3339 is a pretty reasonable profile of ISO8601 <a href="http://www.ietf.org/rfc/rfc3339.txt" rel="nofollow">http://www.ietf.org/rfc/rfc3339.txt</a><p>I'm always a bit nervous when people talk about ISO8601, given that very few people have probably read the spec, and are likely guessing as to its content.

For 99% of use cases on the web, you'll probably manage to get away with the W3 subset:<p><a href="http://www.w3.org/TR/NOTE-datetime" rel="nofollow">http://www.w3.org/TR/NOTE-datetime</a><p>which avoids most of the awkward corners, and for which a parser is a bit easier to write.

Full ISO 8601 is complicated. Try to restrict yourself to RFC 3339 <a href="http://tools.ietf.org/html/rfc3339" rel="nofollow">http://tools.ietf.org/html/rfc3339</a> a profile of ISO8601 if possible.

You can pry my "&#60;milli|micro&#62;seconds since the epoch" timestamps from my cold dead hands.

+01:00 is not a useful timezone. If you want human-friendly semantics for things like "+1 day", you need to use the symbolic name for the timezone (Europe/Lisbon or whatever). If you just want an absolute time, you're better off expressing it in UTC, possibly even as seconds since epoch.

Beware that older browsers, including IE8, won't automatically parse ISO8601 dates, so Date.parse('2012-05-04T12:20:34.000343+01:00') or new Date('2012-05-04T12:20:34.000343+01:00') return the date representation of 'invalid date'. ISO8601 parsing was only introduced with JavaScript 1.8.5. This means that if you're supporting older browsers, you'll need to write your own parser on the client side or use a third-party library (I generally use my own regexp based parser)

If you're sending or storing local dates and times, it may actually be better to use the local time (as ISO 8601 does) with the (Olson tz) <i>name</i> of the time zone it's in, instead of the time zone offset as in ISO 8601. This is more resilient against future time zone rule changes, at least that's what this article argues: <a href="http://fanf.livejournal.com/104586.html" rel="nofollow">http://fanf.livejournal.com/104586.html</a> .

The article doesn't mention the fact that ISO8601 strings will also sort correctly in chronological order, or does this not matter since epoch-seconds do as well (as long as there are enough leading zeroes)?

I never understood what the T was for, besides being visual noise. why not just use spaces?<p><pre><code> 2012-05-04 12:20:34.000343 +01:00 </code></pre> Or, if spaces are not allowed for an unknown reason then:<p><pre><code> 2012.05.04-12:20:34.000343+01:00 </code></pre> Much better, still I prefer the simplicity of this:<p><pre><code> 20120504.122034 </code></pre> In UTC, almost as compact as an epoch, but human readable. Add as many digits as nano precision is needed.

I don't get the argument that timestaps are not human readable -- they are, the only thing you need is a good viewing software. And yes, it is worth it since at least 99.999999% of accesses to this data come from machines.

I don't understand why you would ever use anything other than seconds/micros/millis since epoch. Basically no parsing; Efficiently storable; Simpler; Easier; Better.<p>Only argument I've ever heard is human readability... If you're reading these by hand so often then just write a script/tool/whatever to convert them to human readable. This is still easier since you don't have to find an acceptable ISO8601 implementation. And frankly, how often are you reading the dates manually but not as part of some log output of your program where it could convert it to human readable before logging?<p>This is sending dates the wrong way.

Since nobody else has mentioned this, an interesting essay on time by Erik Naggum; it was done with thought to implementing a time library for common-lisp, but should be readable for non-lisp users:<p><a href="http://naggum.no/lugm-time.html" rel="nofollow">http://naggum.no/lugm-time.html</a>