From: Asmus Freytag (firstname.lastname@example.org)
Date: Thu Dec 08 2005 - 03:21:36 CST
I find Tony's analysis(cited below) very cogent, but I also agree with
Curtis' observation (see his posting) that Y2K has caused a shift in
practice (as evidenced in US forms and websites). Before Y2K the use of
the short date format with four-digit dates in interfaces was relatively
uncommon, if not non-existent. Since Y2K, there are now two competing
short formats. Some organizations insist on a four digit format - others
support the two digit form. Some can handle input in a different form
than output, while others can't (or deliberately won't).
In essence, the situation is analogous to the existence of two locales a
en_US_Customary and an en_US_post-Y2K-unambiguous locale which differ
only in whether they require unambiguous 4-digit years.
CLDR, having a 'one-size-fits-all' model for the US locale is stuck with
having to make a choice - but I think that points to a design limitation
of default locales in general.
It's probably the case that the minute the years go past 31, any
pressure to disambiguate will recede, and, people being lazy, ambiguous
formats will become more common again -- only to fall out of favor 69
If this 'split' between 2-digit and 4-digit form were a universal
feature of (most) locales, then it might make sense to have both short
forms defined, with the 4-digit form the 'unambiguous' short date
format. The downside of this is that selecting a locale does then not
describe the choice of which short date format to use.
If only a few regions exhibit this parallel use of both forms, then
creating standard derived locales for them might be a useful way to
capture divergent practice.
On 12/7/2005 11:33 AM, Tony Jollans wrote:
> I'm new here, so forgive me if I get this wrong :)
> The proposition is that the short date format include the century.
> Much of the comment seems to have been about the now historical Y2K
> issue and what it did or did not achieve, which doesn't really seem
> My understanding is that the Short Date format is part of the
> man-machine interface; it is (a) a format for displaying dates and (b)
> should act as a disambiguator in interpreting human-entered dates; it
> is not (or should not be) an internal format. If this is correct then
> adding the century is (theoretically) prescriptive and would do two
> 1. Impose a century on short date output
> 2. Effectively disallow entry of 2-digit years less than 32 to
> conformant applications
> The first of these doesn't really raise concern; the second seems to
> impose a needless, and not very effective, restriction which would
> not, and could not, take the place of date range validation which is,
> by definition, application-specific.
> It may, in part, reflect an element of good practice but if that is
> the, in my opinion misguided, intention it should not be limited to
> just the US locale.
This archive was generated by hypermail 2.1.5 : Thu Dec 08 2005 - 03:26:26 CST