The Millennium Bug is really two related problems:
1) The first is that software which possesses dates typically ignores the century. For example, 6 April 1998 becomes 980406. This causes comparisons between dates in different centuries to go wrong; notably 2000, recorded as '00', comes before and not after 1999, recorded as '99'. It also means that the software which converts the computer format (binary) into a human-readable data goes wrong. For example, the year which follows 99 may come out as 100, overflowing the available two-digit field and possibly over-writing other data and causing other unpredictable software failures.
2) The second problem is that much electronic equipment contains a clock built into the hardware. Often this is a standard PC clock because the hardware uses standard, mass-produced components to save cost. These clocks usually have the same difficulty with dates in the next century, except that it looks like a hardware rather than software problem. Thus systems, including embedded systems where the great majority of chips is to be found, may fail even if they are not using any time-related functions just because the hardware detects a failure and stops. This will frequently happen either at the first second of the new millennium, or on the first occasion when the equipment is switched off and on again thereafter if there is a 'power-on' self test. Since manufacturers change their component suppliers, or other details of the specification from time to time, to be absolutely sure of millennium compliance it may be necessary to test each unit of a specific model individually.
By David Lyscom in 'UK note on the Millennium Bug'
21. Feb 1999 at 0:00