A Real Y2K Solution
A big part of marketing and sales is to find market niches and position a company to exploit those niches. For the next few months, Y2K looks like a big one. Scott Consulting's sales and marketing team arranged a speaking engagement for me to talk to a local chamber of commerce about Y2K. The purpose: impress an audience with our knowledge and don’t mess it up.
The main point of my presentation was the fundamental problem of Y2K -- 00 is less than 99. That’s what the press says, that’s what analysts say, that’s what conventional wisdom says. But the more I think about it, the more I’m convinced we haven’t looked deeply enough at the Y2K problem.
Even if everyone used four-digit year fields, we would only be putting off the problem for another 8,000 years or so. I know that sounds silly, but we do have computing issues today with longer time horizons. Listen to some of the arguments about nuclear waste storage or read about recent discoveries from the Hubble space telescope.
The fundamental problem is our industry has no universal standard for storing and manipulating time. Even Microsoft is inconsistent across its product line. Excel stores dates as a day offset from Jan. 1, 1900, but Access uses a floating-point format to model dates and times. It seems every operating system and every application has its own way to deal with time, and most of them don’t work well.
We need a standard format for all dates and times and standard interfaces to manipulate them. This standard format needs two attributes: A range wide enough to be worthwhile, and a fine granularity to provide enough precision.
Every operating system would support this standard format and provide the associated standard interfaces. Applications could release new versions with functions that migrate dates from older, proprietary formats to the standard format. After a few years, nobody would have any excuse for another time sensitivity problem.
Borrowing heavily from my friends in the original VAX/VMS engineering group, circa 1975, I propose we adopt a 128- bit integer to store all date and time data. Each bit would represent 1 microsecond -- for the record, today’s OpenVMS still uses 64 bits. If we reserve the high order sign bit, my rough calculations say this standard time field format has a range of a little less than 2 X 10^27 years [2^127/(86,400 X 10^6)]. This format has a range larger than the age of our known universe, with a granularity of one-millionth of a second.
We also need some standard routines for operations such as adding or subtracting an offset to or from a time field, or calculating an offset based on the difference between two time fields. Other standard routines would convert various alphanumeric formats to and from the 128-bit time field format.
A time field may represent either an absolute or a delta time. An absolute time marks an instant in time. January 25, 1999, 10 p.m. is an absolute time. A delta time is the difference between two absolute times, or an offset from one absolute time used to calculate another absolute time. For example, 10 days and three hours from now is a delta time. January 25, 1999, 10 p.m. plus 10 days, three hours gives a result of Feb. 5, 1999, 1 a.m.
Time fields that represent delta times would set the sign bit. Time fields that represent absolute times would clear the sign bit.
Objections? Every 128-bit standard time field gobbles 16 bytes. But with early 1999 memory prices at around $1.50 per megabyte and SCSI disk prices at less than a dime per megabyte, who cares? What costs more, a few megabytes or a massive and never ending date conversion effort across billions of lines of legacy code?
How do we make such a standard happen? I suggest we start a massive, grass-roots lobbying campaign to form an independent group of academics and engineers to refine my time field idea. This group would submit their format to the IEEE and other respected bodies, who would then pressure vendors into incorporating the standard into their products. We consumers would insist all vendors enthusiastically support the standard by rewarding vendors that do and punishing those that don’t.
This could really work if we decide we want it bad enough. --Greg Scott, Microsoft Certified Systems Engineer (MCSE), is president of Scott Consulting Corp. (Eagan, Minn.). Contact him at gregscott@scottconsulting.com.