I am an engineer (electronics) and familiar with real-time control systems. Most of these do not require the year (century) information, but many systems do need to know the time of the day, the day of the week and in many cases, whether it is a holiday.

I propose a workaround that can be applied to many of these control systems. The calendar of 1999 and 1971, as well as the calendar of 2000 and 1972 are respectively the same, except of course for the year. Beginning in 1999, the date/time chips of these system controllers can have a Clinton done to them, namely lie, and tell them it is suddenly the year 1971. The systems will still "know" the days of the week, and that July 4th is a Sunday etc. and run the power plants, traffic controllers etc. correctly. Then these systems will continue to work into the millenium as well. The date logging systems will have the wrong year number, but I think that can be lived with until a permanent fix can be done.

There are of course some chips which may not accept a year earlier than their manufacture, but most will accept any two digits and be happy. It should be possible to reset all critical system clocks over the course of next year, so that when 2000 arrives everything will still run and our lights won't go out.

Doing this is much easier than trying to fix all these chips and programs, many of which are old and unavailable. It is of course not a true fix, but will buy time needed to eventually get these systems properly updated for the next century.

Unfortunately this workaround this will not work for finances, either directly or indirectly, because there the YEAR number is important. Because of this, the problems with banks still be there and must be dealt with. However, even in this area the workaround may buy some time. A point-of-sale system, for example, may not work at all in 2000, but should work Ok if it thinks it is 1972. This will of course print the wrong receipt year and possibly mess up the ordering system, but at least the cash-drawers (yes CASH) will open and the price scanners should be fine also, allowing the store to continue selling.

My workaround should keep the power on initially, but if the banks don't get the problem solved soon enough, the lights may go out eventually, if the power company can't get paid by their customers, nor pay their suppliers.

-- Armin Wolff (arminw@aol.com), November 14, 1998

Answers

Armin,

I have zero computer skills in the field of embedded systems, let me stress that up front. I just want to make sure you understand this is the viewpoint this question comes from.

I am aware of programmable PLCs, but in other systems with true burned in programming, how do you propose to change the date? Wouldn't the internal time be impossible to change?

Rick

-- Rick Tansun (ricktansun@hotmail.com), November 14, 1998.

The city I live in was able to fix their traffic lights that way.

-- anon (anon@anon.net), November 14, 1998.

# # # 19981114

Armin & Rick:

It depends on where the date info is stored ( RAM or KAM - "Keep Alive Memroy ) -- and if you can identify the defective PLC's ( a lot of vendors/users have lost their documentation on a lot of parts ).

Then, where do you get the folks, money and time to "search and destroy" each one? Logistics!

( Related note: Engineers are not always very bright. If you have a system that can figure out HOLIDAYS -- you have, by definition, a system that processes a fully qualified date, too. Duh! )

Regards, Bob Mangus # # #

-- Robert Mangus (rmangus@mail.netquest.com), November 14, 1998.

Like I said, I understand VERY little about embeddeds, so pretty much any info is new to me:)

Rick

-- Rick Tansun (ricktansun@hotmail.com), November 14, 1998.

One thing I think everyone keeps forgetting, let's assume this idea will work without any problems. Let's also assume that the media picks it up and prints it nationwide. There are going to be a huge number of small to medium businesses that still won't do anything about either embedded or computer/software problems. Even if they had the answers to all the problems. The reasons: 1. Don't have the money or people that can do this; 2. Wait to long before starting and run out of time; 3. Here's the most popular one so far: Presented with the facts time and time again, they still think we're all telling them a lie just to make money. Believe it or not, there are going to be a large amount of business owners that cross over from 1999 to 2000 with concrete expectations that nothing will happen. I see it every day. I could list about a dozen examples off the top of my head of people we've SHOWN their actual problems to; and they'll still look at you and tell you you're crazy.

-- Greg Sugg (gregsugg@bbnp.com), November 14, 1998.

This technique is known as 'encapsulation.' It's been discussed several times in this and other forums.

It will work in some areas, not in others. It won't work where the date must be shared unless all users are set to the same date.

As noted, some processors won't accept dates earlier than 1980.

Like most Y2K fixes, it's neither a silver bullet nor is it worthless. It's simply one -- of many techniques -- that can be used.

-- rocky (rknolls@hotmail.com), November 14, 1998.

Every controller I have ever seen had a means of setting the time and date. This is needed in case the power fails and/or the backup battery must be replaced. Also in any system where the time is needed, it must be reset twice a year because of the daylight-standard time change. Whoever does this might as well change the year to 1971 next year. As I said this is not a fix, but a way to buy some time for any system where the CENTURY information is not needed or critical.

-- Armin Wolff (arminw@aol.com), November 14, 1998.

The scope of potential problems of embedded systems is huge. As pointed out, you may not have the ability to change anything on the firmware (e.g., a microchip). Further, even if you could, the date may not go back far enough (e.g., you might be limited to 1980). Finally, just because an embedded processor is not being used in a way that requires it to process date info does not mean that it is not in fact keeping track of the date, due to the "general purpose" way that it was programmed. See the following for a well documented explanation of all this.

Frautschi paper

-- Jack (jsprat@eld.net), November 14, 1998.