On May 13, 12:08 am, Andy Champ <no....@[EMAIL PROTECTED]
> wrote:
> James Kanze wrote:
> <snip>> I added it because I suspect that a lot of programmers forget to
> > test them. Just as they don't take into account that in most of
> > the world, the standard format for entering dates is dd/mm/YYYY.
> > (Or dd-mm-YYYY. Or, if you take into account ISO: YYYYmmdd.)
> I'm pretty sure, with a French sig., you aren't going to be
> one of the people who assumes the world ends at the Rio
> Grande. But I've met an awful lot of people who will check
> all the cases - even to the precise
> 1900-wasn't-but-2000-was-a-leap-year calculations - then
> forget to deal with different human orders in dates.
Interestingly, I think that the risk is actually greater here in
Europe. When you see that France, Germany, Italy and even the
United Kingdom do it the same way, it's easy to think that that
way is universal. Where as in the US, even the military use
day/month/year. (FWIW, I might add that in Europe, Monday is
the first day of the week, not Sunday. Which can also lead to
ambiguities.)
Anyhow, I think we basically agree. I was just reacting a bit
flippantly to your comment about being sure to test on a date
which was ambiguous---I think we can also both agree that there
are a lot of border cases in this domain which typically aren't
tested.
> All your points are good and valid; they just aren't the one
> I was trying to make. We need *both* sets borne in mind.
> Perhaps I am over-optimistic in assuming that leap years will
> be done correctly.
I think most code will depend on the standard library to get
that right, and presumably, it does. The special case I worry
most about is the switches between summer and winter time; will
the software behave correctly if there is no 2:30AM Sunday? Or
if there are two?
--
James Kanze (GABI Software) email:james.kanze@[EMAIL PROTECTED]
en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
|
