Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
16  
I think that the YYYY-MM-DD format is also an ISO standard. –  FrustratedWithFormsDesigner Feb 2 '11 at 15:33
1  
"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
4  
What about different calendars? –  user1249 Feb 2 '11 at 15:36
3  
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
show 10 more comments

10 Answers

up vote 12 down vote accepted

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).

share|improve this answer
7  
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. –  NickC 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
add comment

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.

share|improve this answer
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
    
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
1  
"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
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
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
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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
    
Well, "2011-02-02" is unambigous in any case... ;) –  Martin May 10 '11 at 12:20
add comment

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.

share|improve this answer
    
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
add comment

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).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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