Re: CLDR: 2 vs. 4 digit years in US?

From: Asmus Freytag (
Date: Thu Dec 08 2005 - 03:21:36 CST

  • Next message: Michael Everson: "Re: CLDR: 2 vs. 4 digit years in US?"

    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
    years later...

    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
    > helpful.
    > 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
    > things:
    > 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.
    > Enjoy,
    > Tony

    This archive was generated by hypermail 2.1.5 : Thu Dec 08 2005 - 03:26:26 CST