With little more than 500 days left before the year 2000, Microsoft is still sending out confusing messages about its server and desktop applications that may mask the true extent of the year 2000 problem facing customers.
Officially, Microsoft executives insist that the company's applications are now year 2000-compliant. But many of those assertions gloss over a number of implementation issues that will create havoc for IT managers.
"Microsoft Office has been architected for year 2000 compliance for some time. Office 4.0 is year 2000-compliant with the exception of Access. Office 95 and Office 97 are year 2000-compliant," said Matthew Price, group product manager of the Office developer group at Microsoft.
However, each program within each Office version is "compliant" in its own way, and in some cases each revision of each package has a different formula for recognising two-digit dates.
"For example, if you type in 'February 29' in a field in Microsoft Excel, how that's interpreted depends on the pivot date in the version of Excel you're using," said Robert Lefkowitz, a consultant at Next Era in the US. "In the current version you'd get February 2029. In the previous version, you'd get February 1929. If you were using this data in the year 2000, you'd get February 29, 2000, because Excel knows it's a leap year."
Other issues are also unresolved.
A program written in Access, Excel, or Lotus that uses a two-digit date field may, depending on the version, get stored as 1900.
"Ship dates will be stored incorrectly or if you query the sales for the last month, the program may not pull in all the records. Or, if you're calculating bond maturity dates, as soon as you go to 2030 it will think it's 1930," said Steve Haskell, a senior consultant and year 2000 specialist at Metamore Technologies.
Problems also reside within server applications, such as Microsoft's SQL Server database which won't recognise the year 2000 as a leap year.