On 12-24-96 (09:04) GILLES BEAUREGARD wrote to GERRY DANEN
GB> YEAR 2000 BUG it's more than a 4 digits problems. Until now, lot of
GB> applications writing with Foxpro and others Database language was writing
GB> with only 2 digits for the year, cause it's more efficient to type only
GB> 2 digits than typing 4 digits, a 50% effiency gain. And it's was good,
GB> it's work fine, everybody was happy. And A LOT OF APPLICATION do that,
GB> that way.
Not so.  This has not been true for any .dbf that has followed
the dBASE structure since at least since dBASE III v1.0 came
out.  A date field is _ALWAYS_ stored in the form YYYYMMDD
irrelative of whether you have entered the century or not.
Read up on SET CENTURY on/OFF.
GB> Now, as we approche the YEAR 2000, we must change our programming
Your right, it is obvious, if you're a programmer, or a data
manager that plans on using date differences.
GB> because of our dear Foxpro, can't assume 2000, when you type 00, in your
GB> date field. We have to RE-WRITE ALL APPLICATION. Shame.
You would probably have to rewrite it anyhow, unless you had
already programmed it to check the system date and switched over
to 2000 on the 'evil' day.
GB> How many application you use now and it's orphan, whitout the source
GB> avalaible. A lot.
Yes, and they will pay the price.  So what.  Get busy and start
coding.  Make some money off it.
GB> OK, you tell me, why FoxPro and other have to assume 2000, when
GB> you type 00. It's perfect to assume 1900. You kidding.
Buy yourself a copy of Clipper and use 'SET EPOCH TO 2000' which
supports all dates in the range 01/01/0100 to 12/31/2999.  Then
come back and complain at this time in the year 2996.
GB> Foxpro already assume and do a lot of test on the date field.
No assumptions on date handling to my knowledge.
GB> Try to enter 29/02/2000 and after try to enter 29/02/1900.
Date entry is 'MM/DD/YYYY' not 'DD/MM/YYYY' unless you switch the date
format using 'SET DATE TO DMY'
GB> Which was good, please tell me. And try to enter 12/32/1996,
1900 is not a leap year (28-days). 2000 is a leap year (29-days).
Rule 1: leap year must be divisable by 4.
Rule 2: if so and it is divisable by 100, then is must be also
        be divisable by 400. (2000 = true, 1900 = false)
12/32/1996 would be an illegal date and is reported that way.
GB> your receive an error message, INVALID DATE. So it's assume a lot
GB> by itself.
No apparent assumptions seen here in any of the xBASE dialects
that I've used in the last 10 years.
. use test
. set century on
. append
. list
Long Gone                       12/03/1132
Bob John                        12/02/1792
Judy Dee                        12/02/1900
Mary Lou                        12/02/2000
Freddie Future                  12/02/2990
. set date to MDY
. list
Long Gone                        03/12/1132
Bob John                         02/12/1792
Judy Dee                         02/12/1900
Mary Lou                         02/12/2000
Freddie Future                   02/12/2990
GB> Must of the application for the database was for accountant or
GB> business purpose, and it's cover a short range of time, 5-10 years
GB> in the past and 5-10 years in the future. When you are in 1996 and you
GB> type 00 in a 2 digits numbers we can reasonbly assume it's for the
GB> year 2000, not for the year 1900.
You can't assume anything you want, but the output depends on
(Continued to next message)
--- InterEcho 1.19
---------------