From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Tue Dec 06 2005 - 20:29:12 CST
From: "Mark E. Shoulson" <mark@kli.org>
> 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
seconds.
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