--- [Fair Use: For Educational/Research Purposes Only] WEDNESDAY, DECEMBER 22, 1999

By Michael Hyatt

How do programmers fix Y2K problems?

There are at least three different techniques for dealing with two-digit years.

1. Data Filters. This solution involves creating a "filter" or "bridge" program that detects date patterns in the data input stream. When a two-digit format is discerned by the system, it is converted to a four-digit format before it is allowed into the system. This is similar to how anti-virus programs work on microcomputers or how software "firewalls" work on computers that are connected to the Internet.

2. Pivot Windows. Once the date pattern is discerned it is often converted using a pivot concept or "windowing" mechanism. The windowing option allows programmers to preserve the two-digit date format by designating a "pivot date" to differentiate the centuries.

Regardless of the terminology, the idea is simple. Let's assume the programmer selects a pivot date of "50." Any two-digit dates that are greater than 50 but less than 99 would be assumed to be a 1900 date. For example, "61" would be interpreted as "1961." Conversely, dates that are greater than 00 but less than 50 would be assumed to be a 2000 date. For example, "05" would be interpreted as "2005."

Unfortunately, there are no agreed-upon standards for pivot dates. Some applications may use 30 as the pivot date; others may use 40 or 50. As a result, there will be an incompatibility between applications that make different assumptions. Once again, even with pivot dates or filters, a compliant system is not protected from corrupt data coming into the system in the wrong format or incorrectly interpreted.

3. Date Expansion. Once the date is brought into the system, the programmer must then decide how to store it. He can continue to store it in a two-digit format, using an internal pivot routine to translate it correctly, or he can use a date expansion routine to store the date in a four-digit format. In the latter case, the program expands the actual date field to allow for two more digits in order to accommodate the century indicator. Instead of storing Jan. 1, 2000, as 010100, for example, the field is extended to 01012000. This approach is certainly the most effective over the long-term. However, date extension is also the most expensive to implement. It is time-consuming because it requires changing each date-sensitive line of code, often by hand. And, not only do the programs themselves have to be converted, but all the enterprise's data, input screens, and reports have to be changed as well.

Unfortunately, the above techniques do not work with embedded chips. For the most part, these chips cannot be reprogrammed; they must be replaced.

URL: http://www.worldnetdaily.com/bluesky_hyatt/19991222_xcmhy_how_do_pro.shtml

---

-- snooze button (alarmclock_2000@yahoo.com), December 22, 1999

Answers

"Unfortunately, the above techniques do not work with embedded chips. For the most part, these chips cannot be reprogrammed; they must be replaced."

Not necessarily so. True, if programmable read only memory (PROM) is used, it cannot be re-written. But if erasable, programmable read only memory (EPROM) was used, it can be re-written...assuming that you have the source code or wish to reverse engineer the original program.

-- Mad Monk (madmonk@hawaiian.net), December 22, 1999.

Right Monk, for the most part, these chips CAN be reprogrammed, it's quite common to see EPROMs and EEPROMS used as non-volitle memory. Just another of Hyatts erroneous statements regarding embedded systems.

Regards,

-- FactFinder (FactFinder@bzn.com), December 22, 1999.