Wednesday, March 9, 2011

Helpful tips for US based developers AKA Short date time is evil

English is a bit like html. There is a standard, but not everyone understands it, and there are a number of slightly incompatible implementations.

This is most obvious in spoken English where accents, and idioms vary wildly causing mutual incomprehension.

The last time I was in the USA, I had the following conversation in a restaurant:

Me: Can I have a coke please

Waitress: I’m sorry, what did you want?

Me: A coca cola please

Waitress: I didn’t quite get that. What did you want?

Me (using the British technique of speaking slowly and loudly so the natives understand): A COCA COLA PLEASE

Waitress (getting quite testy): What?

Me: Can I have a Pepsi?

Waitress: I’m sorry, we don’t have Pepsi. Would you like a coke?

English as she is wrote.

The problem with the World Wide Web is the worldwide part of it. Whatever you write, will probably be read by people from a different country. Even if your audience is English speaking, there are enough differences between countries for confusion and irritation to creep in.

A few examples:

  • Last year, Steam had a pre release offer for a game due to be released on 10/12/10(or similar). When is that? My natural reading was Dec 10, but it may have been Oct 12. There was no way of telling without trying to divine the writer’s intentions and country of residence.
  • Last month, I evaluated several rss readers for Win Phone 7. The first one I looked at had the dates hardcoded as mm/dd. If the author had just used the standard system formatting, it would have been correct and less work.
  • I also looked at The Weather Channel for Win Phone 7. There was a setting to use metric units. However even with this selected some (but not all) temperatures were shown in Fahrenheit. As an added bonus, the tile would sometimes show a temperature of -18. Hawkes Bay hasn't seen -18 since the last ice age.
  • In Blogger post options, the Post date is in m/d/yy format

So what do (mostly)US websites and applications frequently get wrong?


Short date time is evil! Repeat that and make it a mantra.

Most of the countries I have visited use dd/mm/yy. The USA uses mm/dd/yy. I believe some countries use yy/mm/dd, but don't quote me on that.

The upshot is that a date such as 09/10/11 is entirely ambiguous without context. Even if the date has some hints, such as 09/17/11, I still have to stop and parse the date rather than reading it. When reading, I devote less than a 1/10 of a second per word. Having to stop, figure out the date, and then start up again seriously screws up my reading.

It's even worse when entering dates, now I have even more opportunity for screwing up. Fortunately most sites have moved to date time pickers or separate day/month/year boxes. Not all have though, one site I was on today used a single edit box with a helpful "dd/mm/yyyy" label beside it.

Blogs and articles frequently refer to seasons. I.e. the new gadget is due in Summer 2011.
This is still problematic; our seasons are about 5.5 months out from the USA so that requires a certain amount of adjustment.

As for the holiday season, WTF? I had to ask an American friend for clarification.

"in general US holiday season means from Thanksgiving (3rd Thursday in November) to the day after new year’s day".

That's not what I would have guessed. If we had a holiday season here, it would start just before Christmas and extend till late Jan. No-one would release anything then, we are all on holiday.

Measurement units
When it comes to measures, there is the US still soldiering on with the Imperial system, and pretty much everyone else is on metric. Unfortunately many sites and applications use just the Imperial measures which is at best an aggravation and at worst requires a quick unit conversion with Google, or more likely, a move onto a different site/app.

Now I understand feet and inches in small quantities provided I don't need to be accurate. Miles require a mental conversion so it has to be something important before I will bother with the maths. After that, I get lost quite quickly.

Ounces are awkward. To my uncertain knowledge, the only people around here who still use ounces are those engaged in buying and selling small amounts of dope. This is not at all useful in performing conversions. Update: I have been reliably informed that the local drug dealers have moved on and now sell in metric units and/or dollar units (e.g. a $250 bag). Pounds are the same as ounces, only more so.

Don't get me started on fluid ounces. I have absolutely no idea how big a fluid ounce is, and no desire to know. This has caused me some aggravation in the past; "How big a drink should I have? Well 60 oz sounds small..."

Number formats
Most countries use "," as the thousand separator and "." as the decimal separator. A few however have it the other way round. Some use spaces for a separator, and the Romans don't even use Arabic numerals.

What to do?
  1. Don't hard code date formats. I use 'dd mmm yyyy' in written text. In my web applications, I mostly use 'dd mmm yyyy'. When I use the system short date time then I make sure that I also use globalisation settings.
  2. Don't hard code number formats either.
  3. Test with multiple cultures. I generally test with NZ and US cultures for dates. I also use Norway or Sweden for testing number formatting.

Why am I picking on the Americans?
American based programmers seem to the be worst offenders. There are 2 main reasons for this:
  1. The USA is a large part of the English speaking market, too large to be ignored for developers outside it. Anyone wanting to sell software into there needs to take account of the US language and units. The reverse is not necessarily true.
  2. Observational bias. If someone was to hardcode metric and dd/mm/yyyy in their applications, I would never notice.
I didn't put my location in the original post; my point is that you should write and program so that others can understand regardless of your, and their, location. Nonetheless, for those that are interested, I live and work in Hawkes Bay, New Zealand.