It is quite common that we need to enter a date into a software or read a date displayed by a software. Often it is paired with a time, forming a timestamp. This might be a birthday or the deadline of an IT project nobody likes to be reminded of or whatever. We deal with dates all the time.
It is a good idea to distinguish the internal representation of dates from the representation used for user interfaces. Unless legacy stands against it, internal String representation of dates (for example in XML) should follow ISO 8601. Often purely binary or numerical representations are used internally and make sense. If legacy stands against this, it is a good moment to question and hopefully discard this legacy.
ISO 8601 is this date format <year>-<month>-<day>, for example. 2012-11-16 (variants: 20121116 121116 12-11-16). I have been using this for the last 20 years, even on paper. What I like about it is that it is immediately obvious which part of the string stand for the year, the month and the date. How do we interpret the date 03/04/05? I also like that the ordering is following established standards. For writing numbers, the most significant digit comes first, which would be the year or the most significant digit of the year. For sorting this format is also obviously better than any other string representation. Another advantage is that this is not the legacy date format of a major country, but is kind of international and neutral, thus acceptable to everybody. Since more and more software and web pages are using this date format even in their user interface, I would assume that everybody has seen it and is able to recognize and interpret it. By the way, I prefer writing it with the „-“ surrounding the month, so it is immediately clear to human reader, that this is a date and it is easier to decompose it. 8 digits are too much for most humans to grab at once.
For the user interface, good applications should recognize user preferences. Most of the time a language setting is around and the applications should follow the conventions of this language settings. Now the official date format for German language in Switzerland, Austria and Germany is ISO 8601, i.e. 2012-11-10 for today, but people are still using the legacy format 10.11.2012 more often and even most software is still clutching to the legacy formats. I would really let the user choose between the legacy format and the standard format, rather than imposing the legacy.
In principal current operating systems provide mechanisms to set preferences and applications should follow them. So it should be sufficient to set the preference of a certain date format together with the language settings once and retain this as long as the user account is valid. But these mechanisms are somehow flawed.
- it can be hard to change the default date format
- is it a setting of the user account, of the specific computer or of the combination of the two?
- Most software of today ignores these settings anyway, at least partly.
- It is quite common that some software uses the localized date format internally and only works if the user has chose this format in his or her account settings. This one really hurts, but I have seen it.
I recommend testing software with really distant language settings, such as Arabic, Chinese or Uzbek (if that is not your native language), to see if it works with any settings. Even if it is possible to use data produced with Chinese when running with Arabic, for example. This might help to eliminate such dependencies, not only those concerning the date format. I consider this useful even if the software is meant to be used only be local users who are supposed to have the same native language. Is that true, no foreigner around who runs his computer with his native language settings? No future plans to use the software abroad, that come up several years later?
For entering dates, it has become a best practice to provide a calendar where the right year and month can be chosen and the day of the month can be clicked. Everybody has used that with good (web-)applications already. But it is useful to provide a shortcut by allowing to enter the date as a string. Several string formats can be recognized, and nothing is wrong with recognizing the local legacy date format. But ISO 8601 should always be recognized. A good example for this is the Linux date command, where you can provide a date in ISO 8601 formats.
In any case the date needs to be translated internally into a canonical format, to ensure that 2012-11-16 and 16.11.2012 are the same.
A suggestion I would make for the Posix-, Unix- and GNU-tools: the „date“ program has been around in Unix- and Linux (and probably MacOS X) systems for decades. Unfortunately the default is to use an obscure US-format for output, ignoring locale settings. I am afraid that it is too late to change this, because to much software relies on this (mis-)behavior. But at least a companion like idate (for „international date“) could be provided that has the same functionality and the same options, but uses an ISO 8601 format as default for its output. fgrep, grep and egrep are examples of providing slightly different default behaviors of basically the same program by providing three names or three variants for it. So I would like to have this:
$ idate
2012-11-16T17:33:12
Maybe I will suggest this to the developers of core-utils, which contains the GNU variant of date commonly used in the Linux world. ls is more friendly, because it recognizes an environment variable TIME_STYLE.
For now I suggest the following for .bashrc (even in cygwin, if you use MS-Windows):
export TIME_STYLE=long-iso
alias idate=’date „+%F %T“‚
Or if you are using tcsh the following for your .tcshrc:
setenv TIME_STYLE long-iso
alias idate ‚date „+%F %T“‚
There are two less well known variants:
Date with week number and week day (1=Monday, 7=Sunday):
2012-W46-5
And even less known year with day of the year (1..366):
2012-321
For conversion:
$ date +%G-W%V-%u --date=2012-11-16
2012-W46-5
$ date +%Y-%j --date=2012-11-16
2012-321
Links
- Markus Kuhn’s article about date and time formats
- ISO 8601 (Wikipedia)
- Converter
- The Best of Dates, The Worst Of Dates
Schreibe einen Kommentar