friendly version of date formats

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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