From: Jukka K. Korpela (email@example.com)
Date: Thu Dec 08 2005 - 15:12:54 CST
On Thu, 8 Dec 2005, Tony Jollans wrote:
>> I'll wager that, when presented with 08/12/05, more people would feel
>> motivated go to their settings and change it to 2005, than would be the
>> case for people presented with 08/12/2005 who would go to remove the
> Probably. But, when forced to type 2005 instead of 05, would that still be
> the case?
The CLDR data is basically for localized _output_, though it may have
indirect effect on input parsing as well. The question is: given a date in
an internationalized format (which can be anything, as far as localization
is concerned, as long as it is unambiguous and easily
machine-processable), what is the specific algorithm (including parameters
like month names etc. when appropriate) for generating a localized
representation? It must be unique, for any particular settings, including
locale settings, though it can be configurable by an individual user.
On input, the problems are different, and we need to consider the pros and
cons of allowing variation in input format.
The reason for short formats like 08/12/05 in this context is not human
laziness (the father of all inventions), since this is not about data that
people are expected to type. This is about data they are expected to read.
Superficially, eight characters vs. ten characters is not a big issue, but
it becomes an issue if you have an array with a dozen columns containing
dates. Admittedly, authors of localizable software cannot assume any
particular limit for the length of the shortest date denotation, but users
may still prefer seeing a table that fits on screen without horizontal
scrolling or that fits on paper in legible font size.
-- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
This archive was generated by hypermail 2.1.5 : Thu Dec 08 2005 - 15:20:20 CST