Friday, February 20, 2009

ISO 8601 is the Only Date Format

I hate dates.

I hate having to convert between dates and times. I hate date calculations (stupid leap year). I even hate date formatting (why must every client have their own preferred format?). Dates are just plain messy.

ISO 8601 (a.k.a. YYYY-MM-DD) eases the mess.

Quick question: what day of the month are the following dates representing?

  1. 2009-01-09 20:18:53
  2. 20090203181210
  3. 02/11/2009
  4. Mar 2, 2009

Either #1 or #4 yield quick, easy answers. Sure, you can figure out #2 with a little work, but why work for simple answers? Format #3 is hopeless because the answer depends on who you ask (and where they're from)—some (mostly to the left of the Atlantic) will insist that the answer is the eleventh day of February, while most others will answer the second day of November.

Follow up question: how would you sort dates in each format? For either #3 or #4, you first need to convert to an internal date representation before comparing. Either #1 or #2 can be compared with no conversion. The string "2009-01-09 20:18:53" is less than "2009-02-08 00:12:30":
>> "2009-01-09 20:18:53" < "2009-02-08 00:12:30"
=> true
The comparison holds true in any language that supports strings (so pretty much every programming language ever designed). Consider javascript:
if ("2009-01-09 20:18:53" < "2009-02-08 00:12:30") alert("yup");
Hell, it even works in fake languages like XSL1.

Another important benefit of ISO 8601 is its ease of conversion to native date format—simply split on dashes. This makes it ideal for a simple yet robust data interchange format.

So format #1 (ISO 8601) is easiest for human readability while still making for simple comparisons and conversions. Ease and simplicity always trump any other concerns.

Ease and simplicity == fewer bugs.

Ease and simplicity == more maintainable code.

I am not arguing that dates should be ISO 8601 no matter what. In the final UI, go with whatever localizes best. But until design aesthetics become significant, ISO 8601 is the format.

Client wants mm/dd/yyyy in a CSV dump? Tough. It lacks readability and can not be easily compared.

Want to save space in a DB string field by dropping the dashes? Wrong. It lacks readability.

Think sticking with the application default of Mon D, YYYY is good for consistency? Consistency, when adding complexity, is the bane of application development.

Always strive for simplicity, for maintainability. In 6 months, which is the easiest for you or another developer to grok? Which is the least likely to cause bugs down the line?

IS0 8601 is the cleanser for life's messy dates.



1 Just because I have this lying about, in XSL:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">

<xsl:template match="/">
<results>
<xsl:apply-templates select="results/result">
<xsl:sort select="date" order="descending"/>
</xsl:apply-templates>
</results>
</xsl:template>
</xsl:stylesheet>

2 comments:

  1. FWIW: the strings won't sort properly once multiple timezones enter the mix. Timezones mess everything up; do your date comparisons in UTC. :)

    Also, if you really want the best properties of ISO 8601, you may want to restrict your use the W3C's subset. But you'll still need to deal with timezones before a plain old string sort will work.

    ReplyDelete
  2. An AWS cloud designer is an expert who can evaluate a business' requirements and make compositional suggestions for executing and successfully conveying applications on AWS. An AWS cloud foundation modeler is an IT master who directs a business' distributed computing climate which incorporates the administration of use design and its organization in a cloud-based biological system. AWS cloud engineer jobs and obligations incorporate cloud reception and application plan and cloud organization and checking. AWS cloud specialists ought to have the authority AWS Affirmation from Amazon which approves their cloud aptitude>> cloud application architect aws

    ReplyDelete