Is there a universal date format that anyone in the world can understand?

Question

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

"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 02 '11 at 15:33
There's always the Julian Day ( http://en.wikipedia.org/wiki/Julian_day ) which should be pretty unambiguous and then the end users can format however they want! — FrustratedWithFormsDesigner, Feb 02 '11 at 15:41
@Thorbjørn Ravn Andersen: I imagine with any calendrical system that breaks time down into years, months, and days will have the same type of problems with potential ambiguity from formatting. — FrustratedWithFormsDesigner, Feb 02 '11 at 15:42
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 02 '11 at 15:50
@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 02 '11 at 15:56
Just present them with the number of seconds since 1st January 1970 and avoid all regional date issues ;) — badgerr, Feb 02 '11 at 16:51
@Job: 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. — Mike Dunlavey, Feb 02 '11 at 16:53
@Job, after some parties you need to start simple - "what year do we have?????". Especially New Year parties. — , Feb 02 '11 at 17:32
@Thorbjørn, :) If you are from Europe, I think the first question that you ask when you wake up after a party should be: what country am I in? And then worry about what year it is. — Job, Feb 02 '11 at 17:43
Peter Török: Here in Austria, and also in Germany, it's DD.MM.YYYY or YYYY-MM-DD; DD-MM-YYYY is very unusual here. — user281377, Feb 02 '11 at 17:49
Seems to me that if there was one, you'd be using it and you wouldn't have to ask this question. :P — Mason Wheeler, Feb 02 '11 at 18:07
@Job, The "ø" is a dead give-away since it is only in Danish and Norwegian. And most european countries are _STILL_ bigger than most eastern US states, so the problem is not that big. — , Feb 02 '11 at 19:30
Just saw this after posting my Crusade for a new data type called ComplexDate... see my post here https://softwareengineering.stackexchange.com/questions/401804/is-date-a-string-or-a-complex-object/401805#401805, which will also partly answer your question, I believe — Hannington Mambo, Nov 29 '19 at 13:15

score 21 · Answer 1 · answered Feb 02 '11 at 15:56

21

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.

answered Feb 02 '11 at 15:56

Kramii

14,029
5
44
64

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 02 '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 08 '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 08 '18 at 13:55

score 16 · Accepted Answer · answered Feb 02 '11 at 15:32

16

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

answered Feb 02 '11 at 15:32

10

And then you can just have a translation file for month names in different languages. – FrustratedWithFormsDesigner Feb 02 '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 02 '11 at 16:49
What about the languages which don't bother naming the months? – JUST MY correct OPINION May 10 '11 at 07:06

score 10 · Answer 3 · answered Feb 02 '11 at 15:41

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.

score 6 · Answer 4 · answered Feb 02 '11 at 19:05

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.

score 3 · Answer 5 · answered Feb 02 '11 at 15:36

3

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

answered Feb 02 '11 at 15:36

score 1 · Answer 6 · answered Feb 02 '11 at 16:28

1

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

answered Feb 02 '11 at 16:28

chiurox

1,498
12
17

score 0 · Answer 7 · answered Feb 02 '11 at 15:37

0

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.

answered Feb 02 '11 at 15:37

yfeldblum

1,532
10
9

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 02 '11 at 19:44
1

Well, "2011-02-02" is unambigous in any case... ;) – Martin May 10 '11 at 12:20

score 0 · Answer 8 · answered Feb 02 '11 at 16:46

0

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.

answered Feb 02 '11 at 16:46

ggambetta

1,204
9
8

1

Roman numerals? "Natural?" – Wonko the Sane Feb 02 '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. – ggambetta Feb 02 '11 at 19:32
+1, I was thinking something like this myself. yet, I also agree with your critics. – Job Feb 02 '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 02 '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

score 0 · Answer 9 · answered Feb 02 '11 at 17:40

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 02 '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 02 '11 at 17:51

score 0 · Answer 10 · answered Feb 02 '11 at 18:57

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](https://en.wikipedia.org/wiki/International_Atomic_Time) — mouviciel, Jun 30 '16 at 07:51

score -2 · Answer 11 · answered Jun 30 '16 at 04:06

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.

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

Is there a universal date format that anyone in the world can understand?

11 Answers11