Use flexible date and time formats and avoid confusing users

(updated 16 Sep 2015 – information about LinkedIn and date formatting issues)

Some developers will hard-code the date and time format in their software. Sometimes this only applies to their English-language interfaces, but sometimes it extends further, which is even more thoughtless. Many American and anglophone Canadian developers tend to impose the ‘Month/Day/Year’ date format on everyone, regardless of what is popular elsewhere. Do not hard-code date and time formats. Either let the user choose it (like Wikipedia) or detect it from the user’s computer settings (like Github).

There are three date formats, listed in approximate order of popularity:

• Day/month/year – Long form: 21(st) January 2015 Short form: 21.01.2015 (most popular in Europe, Central America, non-English-speaking North America, South America, Africa and Western Asia, and used in a military context in the USA). Please note that commas are not used in this date format.
• Year/month/day – Long form: 2015 January 21 Short form: 2015-01-21 (the ISO standard, most popular in East Asia, also used as a standard date format when sorting dates in computing)
• Month/day/year – Long form: January 21(st), 2015 Short form: 01/21/2015 (popular in anglophone North America, particularly the USA; you may see the month/day/year format written in long form by other English-speakers, but not the confusing short form)

Of these three date formats, Day/Month/Year is the most popular. If you asked North American software developers, you’d think it would be Month/Day/Year, even though this date format is only used on a widespread basis in the USA, by some people in English-speaking Canada and Belize.

The Month/Day/Year format can be confusing when written in short form, especially with a date like 03/04/2014 – are you referring to 3 April, or 4 March?

Avoid using numerical dates, where most date-format confusions happen. 10/09/2004 can be 10 September 2004 or 9 October 2004. Write the month name out or abbreviate it using words, not numbers. ‘10 Sep 2004’ and ‘Sep 10 2004’ are unambiguous, unlike 10/09/04 and 09/10/04. You’ll also want to write the year out to avoid confusion. Christopher Heng has an excellent article about avoiding numerical dates on The Site Wizard if you’d like to read more.

Dropbox, a popular cloud-storage provider based in San Francisco, had a hard-coded Month/Day/Year date format (written numerically, to add to the confusion) on the English-language version until the end of 2013, after years of complaints from their international user base. Evernote and Firefox OS are currently the subject of similar complaints. There is a two-year-old thread from Dell users complaining about one of their products having a hard-coded M/D/Y date format if their language is set to English. It should not take five years for a website with an international user base to support date formats understandable by a wide variety of people. People on LinkedIn have been complaining about a default, unchangeable US date format (written numerically on certain parts of the site) for the last two years, with no change in sight. If I am able to change the date format from M/D/Y to D/M/Y on a cheap mobile phone, then I should be able to do it with a smartphone UI or a web app.

What not to do: Apple’s support website shows numerical Month/Day/Year dates for updates, even if you have a region chosen that should change the way dates appear. The first three dates could be ambiguous, especially at the end of the year. I tried this list of updates with both the US and UK localisations of the Apple sites and the date formats didn’t change.

Date separators can also use different punctuation – in English-speaking countries, there are a variety of different date separators, depending on region (the commonest are the slash/stroke and the full stop/period), but in German-speaking countries, people use the full stop.

Give the option for 24-hour time (0:00 to 23:59) and 12-hour time (12:00am to 11:59pm). Most non-English-speaking countries don’t use 12-hour time, and there are many English-speakers who prefer 24-hour time in user interfaces (it’s the standard in UK English regional settings on OS X, Windows and iOS).

Examples of date format flexibility: Windows allows the user to choose any date order they like, even when using English (US) as their region format.

Examples of date format inflexibility: English-language OS X and iOS will only allow you to put the day in front of the month if you’re using a region format other than US or Canada. I ended up changing my region format to UK to get my preferred date order – I hate month/day/year.

Some flexibility, but room for improvement: Trello will detect 12-hour and 24-hour time formats, and will understand different inputted date formats, but the text still shows Month/Day/Year date formats. They’re not numeric, but some users may want to have the dates to be displayed as ’12 October 2015′ instead of ‘October 12, 2015’. (Update, 16 May 2015: Trello now detects both date and time format; the day is now in front for me, which is in line with my date settings on OS X.)

Here is a good example of what to do from Wikipedia – there are no numerical dates except for year-month-day, which is unambiguous, and you have the choice between Day Month Year, Year Month Day and Month Day Year.

Addition, 11 April 2015:

I’m convinced that the US ‘Month/Day/Year’ date format should be avoided in sites that will be used outside the US – and especially websites that will be translated into other languages. People including date formatting in scripts should make the default English format the ISO standard (Year/Month/Day), making regional preferences like MDY and DMY opt-in by specifying a language and dialect. I’ve seen too many websites where the American date format lurks as an artefact, even on localisations for other languages like French and German.