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".
- if today, drop
YYYY-MM-DD and use
- 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
- if not within 1 day, also drop
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
01-01 10:59 You called me
01-01 11:30 I called you
01-27 08:30 I called you
09-12 I called you
08:15 You called me
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.
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
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.