A Sip From The Firehose: May 27, 1996

By: David Intersimone

Abstract: I'm occasionally asked how long I am going to be a programmer and a part of this business. I usually respond with "I'm going to retire one minute before midnight on December 31st 1999 and disavow that I've ever been involved with computers.

Monday, May 27, 1996
Scotts Valley, California

I'm occasionally asked how long I am going to be a programmer and a part of this business. I usually respond with "I'm going to retire one minute before midnight on December 31st 1999 and disavow that I've ever been involved with computers." Upon hearing my response there is usually one of two reactions: 1) a look of wonderment about the response and why I've chosen such a precise date and time, 2) a look of understanding and nervous laughter from an enlightened few.

Why retire at 11:59pm on 12/31/99? Do you know what will happen at midnight in the Year 2000? ATM machines might eat your cash cards. Credit card charges could be refused. Billing statement totals might have outrageous interest charges included. Medical records could say you're the oldest person alive. Books checked out of libraries could be 2000 years overdue. Your MTV could stop playing when you cable bill is 730000 days past due. If the software that is being used has logic that does not take into consideration the rollover of the century, a calculation could cause anything from a humorous conversation piece to a serious software failure to occur.

Many applications rely on date arithmetic. Since the beginning of computer programming it was a common practice to limit the storage of dates (usually involving use of a two digit year) in order to save memory and disk space. If the storage of the year portion of a date is restricted to a two-digit year and the application doesn't handle the logic of calculations that span over the end of the century a problem will occur. This can affect any software logic that calculates based on date, compares dates, or sorts on date.

The Gartner Group estimates that the software maintenance cost to fix year 2000 date problems will be $450 to $600 per program. Widely different worldwide estimates of the cost to fix the problem are in the range of $100 to $600 billion. The demand for Year 2000 expertise has spawned an entire industry. Some industry experts are claiming that this industry could be hotter than all the excitement that surrounds the Internet (at least between now and the end of the decade). Some industry experts are also speculating that the Year 2000 industry will collapse in the Year 2000 faster than an out of date tax preparation software package.

What does the Year 2000 mean to developers using Borland products? If you are using our database products' standard date fields you won't have to worry about the year 2000. The table below summarizes the date support for Paradox, InterBase, all versions of dBASE since version III+, and Visual dBASE for Windows.

If you have written your own code with files that include dates or you use non-Borland database software you may have to worry. Some Year 2000 issues you should review include: 1) database and memory storage of dates that use 2 digits or some other limited precision for the year, 2) code that does date calculations, comparisons or sorting, and 3) non-Borland database software that support date fields (check with your database provider for date field specifications).

If you are worried about Year 2000 issues there is a wealth of information available on the Web (Use a search engine and search for "Year 2000"). While I was surfing I found many home pages and documents about Year 2000 issues and services available to fix them. I also found a freeware tool from Bozeman Legg, Inc. (a consulting company in Davis CA) called the "Year 2000+ Software Analyzer". You can download the software. The software analyzes source code only and runs on any IBM compatible computer running Windows 3.1 or Windows 95.

Okay, I won't retire at the end of 1999. I do hope all developers will take the time to review their code to make sure it handles Year 2000 issues properly. I want my MTV!

Date Field Precision for:
Paradox, Visual dBASE and InterBase

ProductDate Field Range
ParadoxJanuary 1, 9999 BC to December 31, 9999 AD
Paradox correctly handles leap years and leap centuries and checks all dates for validity. Paradox treats all BC years as leap years.
dBASE III+ to Visual dBASE for Windows 5.5January 1, 0000 to December 31, 9999
For all versions of dBASE from version III+ to the current Visual dBASE for Windows 5.5, date fields are stored as a string in the format YYYYMMDD. In dBASE III+ a new SET CENTURY command was added for the approaching 21st century. SET CENTURY ON allows display and editing of the 4 digit year. SET CENTURY OFF limits display and entry of the year to 2 digits. All calculations and storage involving date fields handle the year correctly regardless of the state of SET CENTURY. With SET CENTURY OFF, the command,STORE {01/01/2000} TO MYDATE, will display the year as 00 even though it is stored correctly on disk and in memory as the string 20000101. Note that the YEAR function always returns a 4 digit year.
InterBaseJanuary 1, 100 to December 11, 5941
InterBase supports a DATE data type that stores dates as two 32-bit longwords. An InterBase DATE data type includes information about year, month, day of the month, and time.

davidi@inprise.com
David I

PS: the previous Firehose had an incorrect GotoPage procedure in the OLE Automation Server. If this affects you, it has been corrected, and you may view the corrected code now.


Server Response from: ETNASC04