Re: Dates (was Re: octal error)
On May 13, 12:08 am, Andy Champ <no....@nospam.com> 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@gmail.com
Conseils 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