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!

  • 4
    This really belongs on UX or such. There is a toLocaleString() if you want the computer to take care of displaying it in preferred order
    – mplungjan
    Commented Aug 21, 2013 at 5:49
  • Related: How to read in the 24-hour time system. Most countries use and recognise the International Standard ISO 8601
    – TrevorD
    Commented Aug 21, 2013 at 11:01
  • "... on [d&t]" rather that at. Personally, I prefer the form that you call the shorter version (ISO standard). But then, I do live in a country where that is the normal format.
    – DavidR
    Commented Aug 22, 2013 at 16:42
  • 1
    In US format I would not say 15:42, but instead 3:42pm.
    – GEdgar
    Commented Aug 22, 2013 at 18:27
  • 1
    You've already constrained your solution by deciding to say "at XXX". What about "12 minutes ago"? What about putting timestamps on the left? Does the user even care? It'd be most useful if you explain the task that the user is trying to perform with this information... Commented Sep 12, 2013 at 15:12

4 Answers 4


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.


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

  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

  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

enter image description here

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.

  • As a user, I find it frustrating when the year is dropped. How do I know the difference between "it was this year" vs "we just don't display the year, regardless of what year it was"? It may not matter if the collection of information spans less than a year, but it certainly matters if I'm looking at something historical (eg. this question in a couple years).
    – cimmanon
    Commented Sep 12, 2013 at 18:37
  • You pinpointed the main problem with dropping stuff. "We just don't display the year" is just plain wrong. But if there is any doubt, it should of course be displayed. But there's more to it than just do or don't; you are probably not frustrated that gmail drops parts of dates and times in the inbox list, but while when encountering a new system you are not yet familiar with, the doubt comes up. That's also when the tweaking and user testing part comes in.
    – JOG
    Commented Sep 12, 2013 at 19:34

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:

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

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

2013-09-11 01:25:39 MST-06:00

timezone & date

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!)

  • +1 for "As an American, I give you permission to standardize!"
    – Racheet
    Commented Sep 11, 2013 at 14:21

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.