A natural-language format for time and date

Question

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 1

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:

• Formatting relative dates and times
• Relative dates/times- Rounding and how accurate?

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.

Answer 2

You should ALWAYS keep the most significant numbers to the left, and separate any for-the-human text to the right. If you are using 3-char months, you should never make an exception for the 4-letter months. Either abrieveate them all or write them all out. Don't use slashes or commas with the numbers. Always use a 24 hour times, with a leading zero for hours less than "10".

You should let the user pick whether or not to use [GMT|UTC|UCT|ZULU] which are all the same thing, or local time, and just display that format always. Then you can elminate the timezone from the display, thus reducing the visual complexity to:

YYYY-MM-DD HH:mm:ss
2013-09-11 01:25:39

This is far & away THE finest way of coping with time display. You user knows whether they set their system for local or universal, so you don't need to include that in your output. No needless clutter whatsoever.

Columns of data will always AUTOMATICALLY be sorted in chronological order with no additional effort, on nearly any filesytem or storage method.

If you MUST include the text for month & days, then you get

YYYY-MM-DD HH:mm:ss MMM DDD
2013-09-11 01:25:39 SEP WED

The 3-char text for month & day is superior than full text names, as these columns of data will ALWAYS line up and have the same length, at least until the year 10,000, with NO extra effort on your part.

These formats are extremely good if the data will ever be cut & pasted anywhere, as the data will form neat blocks that are easy to highlight without missing any data.

If you MUST include a timezone, lose the paranthesis for human viewing

YYYY-MM-DD HH:mm:ss ZON±HH:mm
2013-09-11 01:25:39 MST-06:00

timezone & date

YYYY-MM-DD HH:mm:ss ZON±HH:mm MMM DDD
2013-09-11 01:25:39 MST-06:00 SEP WED

AND, make life easy on yourself, don't make separate formats for US & others, just use 1 format for everything. As an American, I give you permission to standardize! (surprise!)

Answer 3

The American format is natural for Americans, the Commonwealth format is natural for non-Americans.

The Commonwealth format is ordered from the least significant (day of month) to the most significant (year).

The American format is not ordered according to significance.

The ISO standard is YYYY-MM-DD which is ordered from the most significant to the least, the same as the time of day and as regular numbers. The ISO standard for time is HH:MM:SS.

Personally, in general, I would default to the ISO standards and let users choose if they want to see another standard.

For event logging, use the ISO standard, as sorting it as text gives you the same result as sorting by date and time.

Answer 4

It depends a lot on how you display and use the datetime data. But the only sure thing is that the user in front of his computer is used to read date time using his local preferences. So even if you use UTC time, try to display to each user the format (not the converted time) he used to read everyday.

• As already said if it's log file ISO 8601 of UTC time.
  

After that it depends of what the time is used for. You could have many useful times.

• It could be UTC time (good for computers synchronisation),
• It could be user in front of computer time (this task is scheduled to be executed every morning at 08h15 local time)
• It could be the local time where the event occurs (the customer receive is receipt in supermarket at 05h12)

Then it depends what the user do with the time

• User can use it in context where only his local time is useful. ( local time/ local time presentation settings )
• User may have to exchange that information with someone using another local time ( go to UTC time maybe iso 8601 )
• User may have to talk to someone using different local BUT that user use time of the event ( store open at 08:00 ) so you could display distant time using user local setting.
• User may need sometimes local, sometimes distant, sometime UTC. if you have a grid you could just add column otherwise maybe hover popup displaying the other useful timezone.

I don't think there is an ultimate solution. Date, time, timezones, daylight saving is always something you should carefully make choices.