DateFormats and Smart People

Uncategorized Add comments

For ~19 years, I’ve pushed international date formats; date formatting is a strange detail that seems to be so significant to me.

Someone (“lion”) whose industry knowledge I strongly respect, and who has an attitude of “what will XXX do for me today?” (ie not flippantly changing direction on things without clear benefit) admitted to switching to international date format.

Why is that so cool to me?

  • it validates my position, but may not yet validate the stubbornness with which I’ve pursued this
  • confirms the benefits are not merely in my biased opinion
  • it’s easier for me personally 🙂 (it’s all about me)

In this case the benefits of ISO-8601 format (the basis for W3C, RFC-3339, used by tools such as XML recommended datatypes) of yyyy-mm-dd being unambiguously understood in other countries, and sorting where least expected (filenames of presentations and revisions of tech pubs) due to its friendliness with sort algorithms no more complex than strcmp(), these benefits have made it easier to find the earliest/latest/newest versions of documents where dozens of similar content may exist.

I still argue that:

  1. Locale is not Language: Just because I’m in China, I may not speak Chinese (and which China? Which Chinese?)
  2. Locale is not format: in Canada, we use date formats dd/mm/yy, dd-mmm-yy, and yymmdd — so which one?
  3. Language is not format: en_CA is similar to en_US, but 2/3/4 is a different date than you think
  4. There are more cities than Timezones: if you’re choosing a timezone, choose a timezone, not a city, unless it helps to suggest the actual timezone
  5. Don’t accidentally get into politcs: Wales and London are not so United of Kingdom; if you don’t offer “Cardiff” and “Bristol” as cities, then allow the user to choose their timezone without claiming to be British (or is that “English”?). If you don’t understand that, spend a week in Wales.

RFC822 and RFC-2822 force foreign countries to know English day-names and Month names (not hard, but entrypoint for error) and require non-trivial parsers, but some developers just don’t seem to consider that there might be an easier way.

Tools that follow java.util.Date or PHP date formats or make assumptions based on /etc/tz values, they’ll continue to limit their users’ choices, further limiting their users’ end-users’ choices. Think about what constraints you’re doing. “Rome wasn’t built in a day”, “you can’t turn a supertanker”, “can’t change China” – you don’t have to try to change the world, just don’t participate in the constraint.

Hey, it’s nice to be right on occasion. Unfortunately, I still need to choose Japan or China as locales in order to get usable dates.

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in