localization - A natural-language format for time and date

I'm looking for an easy-to-read way to format time and date. The time and date will be displayed in a piece of software, and will be used to tell when an event occurred. For example,

"A temperature spike occurred at [t&d]".

Shorter versions of the time and date will be displayed where appropriate. They will use the format YYYY/MM/DD HH:MM:SS UTC±HH:MM.

Given the software user might be in a different timezone, I feel that using natural language (and saying an event occurred 'Yesterday' or 'Last week') is not ideal. I would like to know what other formats of time and date are standard. Currently I hypothesize that the two formats will be:

1. 
   

   "Commonwealth" format: DAY, DD MON YYYY at HH:MM:SS (UTC±HH:MM) eg.

   
   

   
   

   Tue, 30th July 2013 at 15:42 (UTC+13)

   
   

   
   


2. 
   

   US format: DAY, MON DD YYYY at HH:MM:SS (UTC±HH:MM) eg.

   
   

   
   
   

   Tue, July 30th 2013 at 15:42 (UTC+13)

   
   

   
   
   
   
   • DAY is a 3-letter abbreviation for the day
   
   
   • MON is a 3-letter abbreviation for the month unless the month has 4 letters in which case, just use that
   
   
   • The year is optional and will default to the current year if not specified
   
   
   
   

Are my date formats correct and good natural language? Or are there better ones?

Thanks in advance!

Answer

Welcome to the amazing world of time formatting! The best format to use always depends on context and application. Some big products like Skype, Facebook, Gmail, iPhone (Messages) have had a long time tuning and tweaking this art into great examples that you should check out for inspiration. And you will have to do some tweaking, user studying, and revising, too, before it will work perfectly in your app. But here are some general guidelines.

Dropping the obvious part

What I think you are looking for, is dropping the part of the full format that is redundant or assumed if missing. You could put in use that if the year is not given, that means "this year".

Examples using YYYY-MM-DD HH:mm:ss

• if today, drop YYYY-MM-DD and use HH:mm only


• if this year, drop YYYY and use MM-DD HH:mm only

Dropping the details

Another aspect is "zooming out" to see the big picture, by dropping the details if the more significant parts are big, for example

• if not within 1 hour, also drop :ss


• if not within 1 day, also drop HH:mm

Both these methods can be applied to other formats. Depending how you "crop", you might have to change the format, eg writing January 2013 instead of 2013-01, to make it more readable in context.

Grouping

The same method can also be used if the dates and times appear in grouped lists, with the common part broken out into a header. Example

2012

  12-31 08:02     I called you

January 2013
  01-01 10:59     You called me
  01-01 11:30     I called you

  01-27 08:30     I called you

Last week
  09-12           I called you


Today
  08:15           You called me

Time zone

If you are looking at a lot of globally spread data and users, I suggest that you use the flight time system, where all times are local. This way users can more easily communicate with the same format, even though that would have to include a geographic position. Imagine an American asking a European "Have you seen what happened at 08:30 in Ulaanbaatar?", with and without assuming that would mean Ulaanbaatar time.

It is a mess to write the time zone in a simple way. If it says (UTC+ 08:00) or just (+08) I have no idea where it is. If it says Ulaanbaatar I might not know what time difference they have. And if it says both, (+08, Ulaanbaatar), I might still not know where it is. And adding more cities makes it unreadable.

Fortunately, if your users need this info, they will probably have a good understanding of time zones and geography, and you can use the shortest format, (+08), and perhaps use a tooltip for the full printout, or somewhere link to a useful resource on time zones.

If most data and users on the other hand are in the same time zone, you could instead take the Gmail approach and always print the reading users local time. Thereby assuming the user will herself keep track on the few exceptions where the time of an event she is reading is not the same where it actually happened.

Relative times

There have been some UX questions on this already. Check out:

Especially this part by user @Matt Lavoie:

So I like to follow Alan Coopers thought process of "Design for the probable, provide for the possible." That is to say give the user the most commonly needed or useful information, and then provide for them to get into more detailed information that not everyone may want to see.

Use locale!

You mention only two formats. You must always the local format, if your audience varies in culture. Check out this list on wikipedia: http://en.wikipedia.org/wiki/Date_format_by_country

There are plenty of formats that can be mixed up. Where I live, I can get date confused just crossing the border to Denmark. For example not knowing which number is year and which is date, unless you are actively aware which format you are reading. This happens even in countries with the same date format, as there often is a history and common practices of when to use one or the other, when to drop initial zeroes, and so on. We learned two ways to write in school (the old one typically for hand-written letters, and the new one for correct data keeping). Travel a couple of countries with a couple of different formats each, and you will not always be aware of which format you are reading. You might even miss your flight.

Luckily, computer languages can do the formatting for you, which often sorts this out for the user, mistake free.

And as one someone coming from one of the few countries in the world using the mathematically logical ISO 8601 (most significant numbers to the left), I hereby join @Ace Frame's cause and approve all other countries to switch to that one.