Here is another classic problem that everyone has to suffer because the majority of people use inefficient Intel processors or Microsoft software. The (in)famous Year 2000 problem - when all the computers stop working at midnight on 31st December 1999. Acorn, Apple, Unix and Linux based computers of course don't suffer from any kind of problem and will happily be ticking away on 1st Jan 2000, along with all their software packages - which are all year 2000 compliant since the mid 1980's.

However, due to serious oversights in PC design most PC's will have their clocks reset as the rest of us sleep with the security of knowing when we awake our computers will all be ok. The problem lies not just in the software running on PCs (and some older mainframes), but in the BIOS chip on the motherboard itself. This contains the real-time clock as values stored within it.

Rather than go into the exact technical oversights the original designers had, let me give you a couple of tests you can carry out yourself to see if YOUR computer passes the year 2000 test?

Firstly, to see if your BIOS copes with the actual change to the year 2000. Manually adjust your clock so that it is 11.58pm on 31st December 1999. Now physically turn the machine off and leave it for five minutes. Then turn it back on again and see if the clock is still showing the correct time - in the year 2000.

The second test is to see if your BIOS correctly recognises the year 2000 as a leap year (which it is), so again set your clock to 11.58pm on 28th Feb 2000. Again, shutdown and physically turn off for five minutes. Turn on again and now the date should correctly be 29th Feb 2000.

If your machine fails either of these two simple tests then it is NOT year 2000 compliant and you should complain to your supplier. If you've bought it within the last five years I would ask for your money back! Of course, this is not testing all the multitude of software packages which are also likely to fail, simply because they stored the year part of dates as two digits instead of four. Therefore the year 2000 would be represented as 00. I hope the banks don't think we're all 100 years overdrawn!!

Again, this is careless oversight on behalf of the programmers. Most decent software should store the year as four digits. Even if trying to modify existing software where only two bytes are available in databases, why can't programmers change the field from an alphanumeric to a numeric field. This way instead of storing the text "2000", you simply store the number 20, say as an offset in years from some arbitary date; 1980 for instance. This will only occupy a single eight bit byte and thus still fit in with existing field widths. Then all would be needed is to insert a small conversion routine into the relevant date validation routines. Simple. Now, what's all that hype about??