Banks jumpy as leap year may cause PCs to crash

Yomiuri Shimbun

After successfully handling the threat of computer malfunctions due to the date change to 2000 on Jan. 1, financial institutions are now scrambling to tackle another millennium bug problem that might cause computer systems to crash on Feb. 29 of this leap year.

Major commercial banks have said they will have several hundred employees on alert to deal with possible computer malfunctions from Feb. 28 to March 1. At their branch offices, employees will check systems from early in the morning of Feb. 28 until the banks open the next morning.

Automated teller machine manufacturers will also inspect ATMs that are operating over the 24-hour period. If the banks pass Feb. 29 with no major problems, they are reportedly to disband Y2K countermeasure task forces that were set up last year.

The Financial Supervisory Agency said it will lift a freeze on financial institutions from altering their computer systems to develop new products if their computers operate normally on Feb. 29.

Feb. 29, 2000, has been raised as a problematic day because an extra day is not usually added in years divisible by 100, unless that year is also divisible by 400, which 2000 is.

The 365-day solar calendar does not exactly match Earth's cycle around the sun, so an extra day in February every leap year brings it into step again.

It has been pointed out that some computer calendars may not be programmed to recognize Feb. 29 of this leap year as following the 400-year-cycle, and thus may trigger computer systems to malfunction.

link

http://www.yomiuri.co.jp/newse/0221so05.htm

-- Carl Jenkins (Somewherepress@aol.com), February 20, 2000

Answers

Tthe Century Date Bug software remediation effort proved to be largely successful. The potential TEOTWAWKI "Ice Storm" world infrastructure shutdown was reduced to "Bump in the Road" gitiches. Thus, the Leap Year Date Bug in SOFTWARE systems is probably overrated. Systems can generally be reset at rollover by "declaring" the date 02/29/00. In the worst case, if systems "reject" the date, a one day unplanned shutdown of certain sectors of the world system might occur, so bugged systems don't have to deal with the problem day. The main consequence of this would be high public visiability, and thus act to "blow the lid" off the Establishment Y2K Bug coverup. Embedded System Real Date Clocks are another matter altogether. LYDB infected chips will be one day "fast", and stay that way until reset or fixed. Since embedded systems are often hard to find, and/or access; such repair might be difficult and require much time. And, some of these systems control critical infrastructure, such as the power grid, telecommunications, and chemical plants. Hence, the Leap Year Date Bug could bring all that was dreaded for the much ballyhooed Millennium Rollover. Bear in mind: At the Millennium rollover, all embedded RTCs at least rolled over to the same date: from 12/31/99 to 01/01/00. This won't be true on Leap Day! Hence, a "smooth" Millennial rollover doesn't mean the Leap Day event will be so smooth. Also, the LYDB "hits" in the middle of the business week, with all systems at full load; unlike the holiday "minimum load" status at the Millennial rollover, and a few day time "cushion" to fix problems before business commences. Get Prepared, or Stay Prepared!

-- Robert Riggs (rxr.999@worldnet.att.net), February 21, 2000.