In Canada, everyone is familiar with the date format YYYY-MM-DD. In Europe or South Africa, they prefer DD-MM-YYYY. There are users from South Africa who get confused with the YYYY-MM-DD date format. Is there a way to handle this situation?

I was thinking of using the following method format for all: Feb 02, 2011

  • 21
    I think that the YYYY-MM-DD format is also an ISO standard. – FrustratedWithFormsDesigner Feb 2 '11 at 15:33
  • 2
    "In Europe or South Africa, they prefer DD-MM-YYYY." Except e.g. in Hungary (YYYY.MM.DD) or Finland (DD.MM.YYYY), or ... Sorry, reality is messy :-( – Péter Török Feb 2 '11 at 15:33
  • 6
    What about different calendars? – user1249 Feb 2 '11 at 15:36
  • 4
    When collecting radar data (in North America), we used this for file names: prefix_1999_12_23_16_45_53.ext. Main reason: this was darn easy to sort, SEARCH and parse. When searching, you really do want to start with the most significant unit first in order to reach the goal ASAP. This sort of string is even binary-tree friendly. The lab was dominated by students from Europe, but I think this was just common sense, if not a scientific standard. However, in a country where I grew up, we would use DD-MM-YYYY for everyday use. Reasoning: when you wake up, what is the first part you want to know? – Job Feb 2 '11 at 15:50
  • 2
    @Frustrated, I guess his point is that there are calendars with a different starting year (how would a muslim interpret e.g. 30.12.1268?), or moon months (of which there is approx. 13 per year) etc. So to be really universal is more than just agreeing on which number is the day and which is the month... – Péter Török Feb 2 '11 at 15:56

11 Answers 11


The ambiguous part is to differentiate day from month if they're represented by numbers.

Does 02/03 means February 03 or March 02?

By changing the month identifier from its number with its name you remove that ambiguity. To answer your question, your variant of Feb 02, 2011 seems to be a good solution.

There is still a potential issue with the year number if you're writing it with 2 digits only, but then it's easy to fix (use 4).

  • 10
    And then you can just have a translation file for month names in different languages. – FrustratedWithFormsDesigner Feb 2 '11 at 15:35
  • 1
    @FrustratedWithFormsDesigner And don't forget to get a professional translation to the correct (well-known) abbreviations as well. – Nicole Feb 2 '11 at 16:49
  • What about the languages which don't bother naming the months? – JUST MY correct OPINION May 10 '11 at 7:06

No. There is no universally recognised date format.

ISO 8601 Defines an international standard for date formats. As such, it is probably the best compromise. But as you say, users don't always like this format.

The only correct solution is to present a different format for different countries. You may find that there is a standard library for achieving this if your chosen programming language has a significant following.

  • 2
    This is great. I usually use YYYYMMDD for logfiles, etc. Now I can say I'm just being ISO-8601 compliant! – Mark Harrison Feb 2 '11 at 17:58
  • 1
    When using ISO 8601 I usually find it's best to format the entire thing explicity ie 1999-12-25T00:00:00.000Z. Yeah it looks like gibberish to the average person but there's no chance of ambiguity. – MattDavey Nov 8 '11 at 16:02
  • 2
    "The only correct solution is to present a different format for different countries." - and how, exactly, should I be printing out a date on a packing slip that could ship anywhere in the world? – Scott Whitlock Mar 12 '13 at 20:05
  • 1
    @ScottWhitlock: Sadly, there is no universally accepted solution to this problem. If you don't know where a package is being sent when you print the date, then ISO 8601 may well be your best bet. – Kramii Jun 30 '16 at 15:01
  • 1
    "The only correct solution is to present a different format for different countries." I'd say this is not correct. It just so happens today that some librarys helpful idea of my preferred date format, -based on my preferred languange, -caused confusion. But as a first step since we can't fix all cultures right now, either use ISO 8601 or text for months or something. – Erik I May 8 '18 at 13:55

You should use the culture info for that. Or at least the local display format.

In JavaScript, you can use the toLocaleString method for the Date class.

For C# you can use the format string when using ToString.

A quick Google search should show you how to use the culture in the language of your choice.


I would go with YYYY-MM-DD (and always write out four-digit years and two-digit months and days). YYYY-DD-MM, to my knowledge, is uncommon-to-rare, so the YYYY-MM-DD format is the one with the least ambiguity, and eventually your users will catch on. Also, you get the trivial-sorting advantage.


Can you give each user his/her own locale, which then renders dates and other information according to their local preferences?


Many times you can configure locale and using I18n in most frameworks.


You will, in the general case, need to specify both the format and the value. This is the only way to avoid any and all confusion. For example, you can say "2011-02-02 (YYYY-MM-DD)". It comes at the expense of simplicity and readability though, so know your audience.

You can, of course, say "Hereafter, all dates are in the format YYYY-MM-DD...." Then "2011-02-02" appearing later on will be unambiguous. That can be more palatable, but again, know your audience.

  • Right, except that in Estonian day = päev and month = kuu, in Filippino they are: araw and buwan, in Finnish: päivä, kuukausi, in Hungarian: nap, hónap, in Indonesian: hari, bulan, in Malteese: jum, xahar, in Romanian: zi, lună, in Turkish: gün, ay, in Vietnamese: ngày, tháng ... not to mention many languages where either month does not start with m or day does not start with d (German: Monat, Tag) as well as languages which do not use anything like Latin alphabet. – Job Feb 2 '11 at 19:44
  • 1
    Well, "2011-02-02" is unambigous in any case... ;) – Martin May 10 '11 at 12:20

This suggestion is probably useless, but I've seen months written as roman numerals. Sure, 3/XI/2011 may be november 11 or march 3, but I guess the first interpretation is more natural.

  • 1
    Roman numerals? "Natural?" – Wonko the Sane Feb 2 '11 at 18:37
  • @Wonko, "natural" in the sense that in that context XI is more likely to be interpreted as a month than as a day. I admit it's extremely subjective. – ggambett Feb 2 '11 at 19:32
  • +1, I was thinking something like this myself. yet, I also agree with your critics. – Job Feb 2 '11 at 19:35
  • Having never, ever seen that format, I'd first think "typo" or "translation error" before it dawned on me "Roman numerals." Only then would I try to guess at the meaning. – Wonko the Sane Feb 2 '11 at 20:24
  • Not to mention that 3/II/2011 will end up being interpreted as November. – MSalters May 23 '11 at 15:15

I would say that it depends on what you are doing, how much control you have over the input, and are you storing it somewhere?

For storage, I would use what was suggested by Mike Dunlavey:

YYYYMMDDHHMMSS where the hour is in UTC is the way I go whenever I have a choice, for the reasons you give. When I don't have a choice, I let the user choose.

He did not leave this as an answer, so I will.

One more thing: check out the following screen shot of how to enter CC expiration date: http://www.ubercart.org/files/credit_card_checkout.jpg

The great thing about this example is that it does not make you think. It uses both numbers and names for the month. I would consider using something similar for the input. For the month, include both the number and the localized name. For year and day use numeric Up/Down or combo boxes. Then, the calendar control also seems nifty.

As I said, it depends. For storage: if using a database, check if it already provides a good unambiguous data format. If using some other method, see if "YYYYMMDDHHMMSS where the hour is in UTC" helps. For presenting it to the user - take in consideration what countries / locales can be possibly involved, then pick the most straight-forward, "Don't make me think" kind of representation. Also consider providing an option.

Finally, check out some cool products which already do something similar, and try to find out how they do it.

  • ah crap, when reading the screenshot I thought we were talking about november 11th... only to realize the day was not necessary when talking about expiry date of Credit Card :/ – Matthieu M. Feb 2 '11 at 17:47
  • @Matthieu M., yes, that is a bit misleading :) However, if you are holding a CC in your hand and are about to perform data entry, then perhaps it helps more than it hurts. If there were three boxes - one for the day, then this might be less ambiguous. – Job Feb 2 '11 at 17:51

There is no universal date and time format for web site's end users. There is also no single date time value because the value is different per client's time zone. You should use globalization - its targeting of data, time, currency, calendar, nubmer formats based on users's culture (can be received from accepted languages passed from user's browser or by switch implemented directly in your application). Some APIs (for example .NET) has direct support of this features.

For storing date and time in databse use universal format - UTC (coordinate universal time).

  • UTC is not that universal: If you want to take leap seconds into account you should use TAI – mouviciel Jun 30 '16 at 7:51

It is unfortunate that all the intelligence in the international computing world cannot crack this nut.

Not Microsoft nor other vendors have consider adding a date-mask that would make the Month appear zero-filled, much like the Day, but as three digits. Adoption of practise would help promote a new series of modified date formats which are mathematically equivalent while remaining easy to identify and distinguish in any of the traditional date layouts. That is:

  • 0MM-DD-YYYY, e.g. 002-03-2016 for Feb 03,2016

  • DD-0MM-YYYY, e.g. 03-002-2016 for 03-Feb-2016

  • YYYY-0MM-DD, e.g. 2016-002-03 for 2016-02-03

  • YYYY-DD-0MM, e.g. 2016-03-002 (if anyone wanted to use it!)

Seems too easy to fix it this way ... I guess simple just does not sell well.

  • 2
    All I can say is: xkcd.com/927 We already have an ISO standard for dates, and don't need another one. – Simon B Jun 30 '16 at 9:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.