Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

The users of my application have the ability to choose their prefered date format between:

  • dd/mm/yyyy
  • mm/dd/yyyy
  • yyyy-mm-dd

The 1st one (which has the Java pattern dd/MM/yyyy) produces 31/12/2011.

I've decided that a more friendly version of this format (specifically for email notifications) is the pattern E dd MMM yyyy which produces Tue 11 Jan 2011.

I need help figuring out the "email friendly" version for the other 2 versions (2nd and 3d).

For example for the last version is it acceptable to simply use E yyyy MMM dd which will produce Tue 2011 Jan 11? Is this readable?

share|improve this question
3  
You might find the answers to this question helpful. ux.stackexchange.com/questions/3009/… –  Patrick McElhaney Jan 11 '11 at 18:38
    
@Patrick McElhaney: thanks. It was great info. –  cherouvim Jan 11 '11 at 20:34
1  
What kind of application is it? –  Rahul Feb 18 '11 at 10:05
add comment

9 Answers 9

up vote 4 down vote accepted
+50

For the second version I'd use E MMM dd yyyy. This will produce 'Tue Jan 11 2011'.

I'd be tempted to leave the last format alone. One of the reasons for choosing Year/Month/Day format is to ease in the sorting of data by date. Adding the day name at the front of this and changing the month number to a name will break that sorting ability.

If you need to show the name and sorting isn't an issue then something like

2011 Jan 11 (Tuesday)

as suggested by ICR in the comments might work.

share|improve this answer
    
The expanded version will only be used in email communication which needs to (somehow) contain the day. What would you suggest? –  cherouvim Jan 11 '11 at 16:29
    
@cherouvim - I'd add it on the end. –  ChrisF Jan 11 '11 at 16:31
1  
Possibly in paranthesis e.g. 2011/01/11 (Tuesday) –  ICR Jan 14 '11 at 13:13
add comment

I would assume your users would choose the date format based on the short format most common in their region.

Therefore you should pick the long format that is commonly used in the same regions where the short format is popular.

UK: dd/mm/yyyy -> Tues 7th Dec 1941

US: mm/dd/yyyy -> Dec 7 Tues, 1941

??: yyyy-mm-dd -> 1941 Dec 7th Tues

I'm not an exert on localization, I got the above formats are straight from Wikipedia:
http://en.wikipedia.org/wiki/Calendar_date

The best approach would be to ask your users directly and see what they would expect in each case. You should also consider letting them choose this format in the same way they choose the short format.

share|improve this answer
    
+1 for "pick the long format that is commonly used in the same regions where the short format is popular." That's all there is to it (but remember the long format might or might not reflect the order of the elements in the short format - this is not a technical issue). –  edeverett Feb 22 '11 at 12:40
    
+1 for formats 1 and 3. –  Danny Varod Feb 23 '11 at 19:44
add comment

Summary

  • use numeric formats, YYYY-MM-DD is the best international date format
  • use a readable format if internalization is not a problem
  • use the (HTML5) <time> tag, if possible
  • try to avoid using a date to pass complicated information

The best way to shoot yourself in the foot is to write it 01/02/03 which can be quite a number of things: 1st of February 2003 (European style), 2nd of January 2003 (USA style), or 3rd of February 2001. Formats like 01/02/2003 solve part of the problem but not all of it (see difference in US and EU style).

You then have the internationalization problems, something like the month August can't be safely contracted to Aug and expect people from non-english countries to understand; meaning writing something like 01 Aug, 2003. See wikipedia list of names for August for some clarification. Using numbers instead of names you avoid this problem; however that invites the problem above of ambiguity between month and day and year.

If you're aiming to please everybody the best alternative is to use the ISO standard which is YYYY-MM-DD typically (I recommend avoiding the exotic variants of the standard). If nothing else at least you're using something that's an international standard, for your international audience; the date is also hard to mistake, albeit not foolproof.

If internalization is not a problem (ie. you are aiming for a specific language; writing a email, article, etc) then simply write the readable version: 5th of December 2011, or just simply 5th of December, if the year is the current one. This makes sense because you want to have a consistent style, and you also want to have easy to read inline dates: "The meeting is on the 5th of December. I'll be there on the 4th. Afterwards we should plan for the follow up on the 10th of January 2012." The fewer date formats you use the easier it is for the user/reader.

If you're using HTML you can also make use of the <time> tag: "The conference is on the <time datetime="2011-12-05">5th of December</time>"


There are also several cases where a date is not so user friendly as an alternative approach. One of the most common cases is the use of dates to refer to something like the start of a contest or the end of a contest. There's no need to force the burden of running though conversions in time, timezone and daylight savings nonsense for your user to know this. Worse still, this typically involves the users leaving your site and going to some date conversion site.

What you should be doing (in the case of the example) is provide a date along with a counter. Preferably your own, but using a simple counter service on the web works just as well. Having a counter simplifies the users life, because telling someone a event is X days from now makes it much easier for them to convert to a date in their head.

So, always consider if you can avoid using (only) a date, and what information the users are suppose to get from the date.

share|improve this answer
    
Thanks for bringing <time> to my attention. Edit: Oops... that's HTML5. Until I do the switch I think I'll use a microformats alternative: microformats.org/wiki/datetime-design-pattern –  cherouvim Feb 21 '11 at 6:50
add comment

Depending on what kind of application it is, my recommendation would be to remove the option to specify your own format. The task of specifying a date format is in itself complicated and requires "programmer thinking", eg. you need to parse the abstraction of "yyyy/MM/dd" and imagine what kind of date it will display.

Rather than delegating the responsibility of deciding which format is best to your users, choose the optimal one for the largest percentage of your userbase yourself and use that. Since I don't know what kind of app you're talking about, I can't recommend one, but my experience has been that writing dates the way people say them usually works best. That would mean "Friday, Feb 18th, 2011" - note the use of commas and "th" to break things up a bit.

Notable caveat to this argument: if your app requires users to sort dates. As ChrisF indicates, you might want different options in this case. But since you mentioned "email friendly" formatting in your question, I thought you might be able to use this.

share|improve this answer
1  
It's a global application which relies heavily on the user working with calendar and dates. That's why I most probably need this option in the user settings which is something that most users will never see eventually since I plan on auto-picking the best option upon registration using ip-to-country resolution. –  cherouvim Feb 18 '11 at 11:02
    
Allowing users to select their own date formats does not have to involve parsing abstractions. You can avoid that by simply giving examples. i.e. "Choose a date format: [2013-07-31] or [2013 July 31st] or"... –  A.M. Aug 7 '13 at 2:30
add comment

If you need date due to more formal related matters, I think you would use long date display following default regional settings. In this case, it doesn't matter user settings.

You might use:

  • 11 January 2011 in America
  • 2011 January 11 in Hungary
  • January 11 2011 in UK

If you like to use short date display, more informal. You could format date according to user settings:

  1. dd/MM/yyyy -> 11 Jan 2011 or 11-Jan-2011
  2. mm/dd/yyyy -> Jan 11 2011 or Jan-11-2011
  3. yyyy-mm-dd -> 2011 Jan 11 or 2011-Jan-11

I learned it in: http://www.mscui.net/DesignGuide/Pdfs/Design%20Guidance%20--%20Date%20Display.pdf

Hope it helps,

Iban

share|improve this answer
add comment

1) dd/mm/yyyy (European - least significant to most significant order) -->
  Wednesday, the 23rd of January 2010   or   Wed, 23rd Jan 2010

2) mm/dd/yyyy (American - unordered) -->
  Wednesday, January 23rd 2010   or   Wed, Jan 23rd 2010

3) yyyy-mm-dd (Sortable - most significant to least significant order) -->
  January 23rd 2010, Wednesday   or   2010 Jan 23rd, Wed


1 & 3 are because the day of the week is the least significant number
(fastest changing together with day of month, but with a smaller ranger than day of month).

2 is because, while Americans can be strange in some ways, they are still people, and the first thing a person says when you ask what day it is, is the day of the week.

share|improve this answer
add comment

A lot has been said here - for me as European, the US date is always full of surprises (especially within the first 12 days of a month :-)

I think if you have users from US and Europe, differentiating the formats like this could be helpful

mm/dd/yyyy US

dd.mm.yyyy EU

Also as you suggest, putting in the abbreviated month helps a lot (Jan 12th vs. 12 Jan ).

Apple Mail does a nice thing in the email lists in that it replaces the actual date time with e.g. "Today 10am" or "Yesterday 4pm" as date received. This will not work for emails sent where you want to attribute the exact date, but for online UIs that the user refreshes, this makes a lot of sense.

In RHQ (rhq-project.org) we do something like this for dates alerts have fired ( e.g. "4 minutes ago" ). This way the user does not have to look up the wall clock and do the math himself.

share|improve this answer
    
Today 10am and 4 minutes ago are great. I use them as well. In this question I'm only interested in dates though. –  cherouvim Feb 24 '11 at 10:04
add comment

Your second format is less readable for a European like me.

Bottom line, let the OS format the datetime for your users! Were asking the language of the user to which the e-mail has to be sent. Then we format the date using those culture settings.

share|improve this answer
    
By OS you mean operating system? This is a webapp so I don't have any access to that. Also I don't have a language/country setting, just the timezone. Maybe in the future I'll grab the country via IP->location. –  cherouvim Feb 19 '11 at 6:36
    
Emails are text only, no DateTime for .ToString() in them. –  Danny Varod Feb 23 '11 at 19:29
add comment

I choose Java pattern (31-12-2011), more simple, more general and best known by user.

share|improve this answer
    
Thanks but this is not exactly what I'm asking. –  cherouvim Jan 17 '11 at 6:49
6  
It's also not correct. It's a pattern known and recognized by a lot of European countries, but us pesky Americans and people who think like us tend to want the month first. This fundamental disagreement is why localization was invented. Also, when the date is 03-02-2011 is it March 2 or February 3? Without another date where the day is higher than 12 the user may never know.... –  Berin Loritsch Feb 18 '11 at 13:15
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.