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