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

From: Philippe Verdy (
Date: Tue Dec 06 2005 - 20:29:12 CST

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

    From: "Mark E. Shoulson" <>
    > Michael Everson wrote:
    >> At 02:50 +0300 2005-12-07, Bashar wrote:
    >>> off topic question, why its mm/dd/yy and not dd/mm/yy (or yyyy) in the
    >>> US too (or is it in Europe and other part of the world except arab
    >>> world) ?
    >> It doesn't matter. The question is whether the US locale should be
    >> mm/dd/yy or mm/dd/yyyy. I think it should be the latter.
    > After all the fuss about Y2K six years ago, how can anyone seriously
    > consider two-digit years? This shouldn't even be a question.

    Almost all the fuss was unjustified, and infact proved to be not a problem,
    because databases already store years in machine-readable format that
    includes the complete year, or using a time counter with simple units like

    Seriously, the CLDR is not meant for generating machine-readable data, but
    to build user interfaces targeting human beings in their language. The Y2K
    "issue" was about behavior of programs exposed to date data, but it forgot
    that these hidden interfaces better use simpler formats basedon simpler
    units which are (should be) neutral to the user locales.

    More serious will be the case of programs that still handle date andtyime in
    32-bit formats, which is limited in range, andfor which there's no easy way
    to determine how the counters are cycling (the 2038 limit inherited from
    POXIX timestamps, if not converted to unsigned 32-bit, could be a limit if
    there still exists normative interfaces based on 32-bit timestamps,andIfear
    that it's even more difficult to change in programs,where dates have been
    handled as 32-bit ints. However let's hope that at this time, 32-bit
    processing will be viewed as prehistoric with 64-bit processing everywhere).

    There has already been, since Y2K, several similar date limits crossed
    without real problem. The last one occured in 2004, the next one will be in
    2012 (Ican't remember which limit will be reached that year), and after
    2038, there will be 2039, 2059 and 2079 (for unsigned or signed 16-bit date
    stamps counted in days since 1900, 1950 or 1970).

    In fact, the "Y2K" bug did not occur and did not have the expected impact
    simply because there are already lots of alternative encoding formats which
    allow easier computing, more compact andmore precise storage ofdate/time in
    databases than the conventional 6-digits humane format for dates, and for
    exchange of dates between heterogeneous systems, this humane format,
    alreadyknownto be ambiguous acrosscountries, wasextremely rarely used, as it
    was simply more complicate to process thanusing a single international
    format like the complete ISO 8609 form, or timestamp counters.

    This archive was generated by hypermail 2.1.5 : Tue Dec 06 2005 - 20:38:41 CST