What system default date format to use?

Question

I'm setting the standards for our application.

I've been wondering, what default date format should I choose to use ?

It should be:

• Internationalization & timezone aware, the format should be able to represent user local time
• Can be efficiently parsed by SimpleDataFormat (or alike, jdk classes only)
• Programming Language agnostic (can parse in java, python, god forbid C++ :) and co.)
• Preferably ISO based or other accepted standard
• Easy to communicate over HTTP (Should such need arises, JSON or YAML or something in this nature)
• Can represent time down to seconds resolution (the more precise the better, micro seconds if possible).
• Human readable is a plus but not required
• Compact is a plus but not required

Thank you,
Maxim.

Answer 1

yyyy-MM-ddThh:mmZ (See ISO 8601) You can add seconds, etc

You can read it easily, it will not be a problem for SimpleDateFormat.

Answer 2

The most canonical and standard form is probably "Unix Time": The number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970.

If you set that as the default time-format you can easily parse it, store it in memory, write it to disk, easily communicate it over HTTP and so on. It is also definitely an accepted standard, and in a sense it is "time-zone aware", since it is well-defined regardless of time-zones.

(This is the format in which I always store all my time stamps; in databases, in memory, on disk, ...)

Answer 3

The "right" default format really depends on what you're doing with it. The formats for parsing, storing, and displaying can all be different.

For storing the date you're (almost) always going to want to use UTC as aioobe says, even when you want to display it in user local time. I say "(almost)" but I really can't think of a case where I would not want UTC for a saved date. You may want to store the TZ information for where the date originated also, so you can report it in that local time, but more often you want to display the local time for the whoever is currently looking at the date. That means having a way to determine the current user's local time regardless of what the original local time was.

For displaying it, the "default format" should usually be determined by the viewers locale. 08/09/10 usually means 2010-Aug-9 in the U.S. ("Middle endian") but normally means 2010-Sep-8 in most of the rest of the world ("Little endian"). The ISO-8601 format "2010-09-10" is safe and unambiguous but often not what people expect to see. You can also look over RFC-3339 for Date and Time on the internet and RFC-2822 for message format (transmitting the date)

For parsing a date, you'll want to parse it and convert it to UTC, but you should be fairly flexible on what you accept. Again, the end users Locale and timezone, if discoverable, can help you determine what format(s) of string to accept as input. This is assuming user-typed strings. If you're generating a date/time stamp you can control the form and parsing will be no problem.

I also second BalusC link which I hadn't seen before and have now favorited.