File year2000.txt; written for JDB, but available to others. E-mailed via SS on 1997/12/15. AeroSnail-mailed 1998/01/22. 8<------------------------------------------------------------------------>8 Copyright © J R Stockton, Surrey, UK. All Rights Reserved. www.merlyn.demon.co.uk or JR.Stockton@physics.org Now >= 2001-11-20 Although Web-visible, this file is plain text for practical reasons. Its present Web reference is http://www.merlyn.demon.co.uk/year2000.txt and it will continue to be updated there. (* Acronyms ending in "B" are personal identities. *) *** THIS WILL BE MAINTAINED IN 2000 WHILE EFFECTS MAY CONTINUE TO APPEAR *** =========== THE "YEAR-2000" AND SIMILAR PROBLEMS ========== = ORIGIN = The Year-2000 (or Y2k) problems exist mainly because designers and users have omitted to allow for the first two digits of the year being other than "19" - this tends to lead to arithmetic and logical program errors (on 1999-12-31, Romeo was about 3 years old; on 2000-01-01, he may seem to be about -97, or 97, or ???). It may also give data alignment errors; if the year after 1999 gets written as 19100, adjacent information may be corrupted or misplaced. Many media reports are simplistic; some recognise only the relatively unimportant PC calendar rollover error or just errors appearing at 2000-01-01 00:00:00. = EFFECTS = It seemed to me that the biggest problems on 2000-01-01 itself could be with real-time control systems (such as security/safety systems, Air Traffic Control and JIT; and including "embedded-processor" systems) that fail unexpectedly or otherwise; the biggest problems overall during 1998-2002 would be with business management, finance, and accounting; and the most widespread problems would be generally with small systems (including medical equipment) and personal computers (least important). There may also be annoyances with modern domestic appliances, where these deal with the date (VCRs, etc). Weekdays and Leapdays may be miscalculated; the date may need resetting to allow any normal operation (and the instructions may be lost). Some real-time systems may have failed to handle the actual rollover, while being OK after resetting; others may have failed to operate correctly after being set to any date from 2000 until reconfigured, reprogrammed, or replaced. This includes transport systems, and perhaps the workings of modern cars; be sure not to rely critically on these. Many (but not all) organisations realised, but perhaps not soon enough, that they had a considerable amount of remediation work to do on their systems. Some thought that they had no problems. A major difficulty is that, in general, programmers and users will be given rather little credit for fixing or avoiding the problem in advance of management getting seriously alarmed about it, by which time it will usually be too late. Some people think that there will be minor annoyances, but no great problems, in 2000; some think that there will be business, financial, and civil disaster; some expect something in between. Nobody really knows yet; we will not know for sure until it has happened. Various other dates are critical, in various ways, on various systems. Note: much general debate assumes USA, IBM mainframes, COBOL/Assembler. Remediation will have been impeded, it seems, by the work required for the introduction of the Euro and of Scottish Tax, causing much rework of financial systems. Note also : because a prudent management will be imperfectly confident in the satisfactory operation of all their systems at the start of 2000, there should be pressure on all relevant members of staff to be available on all working (and even other) days at the beginning of the year; therefore, it may be impossible for them to take holidays then. = PC-SPECIFIC PROBLEMS = The PC's Real-Time Clock Chip (RTC) and BIOS may not handle the 1999-to-2000 transition automatically - this will be very common. It means that, at the first turn-on in 2000, the year will be wrong and probably the date and possibly the time (this *will* happen on your family Elonex; train RGLB). If so, just turn on into MSDOS, and correct the settings immediately with DATE and TIME. If you can't do that, put things right in Windows, and close down. Then turn fully off and restart. If there may be dated licenced software on the hard disc, do these boots from floppy disc, without Windows. If you *must* leave it on over the transition, preferably be in MSDOS, and explicitly correct either date or time as soon as it thinks 1999 is finished. There should be *no* rollover problem after this has been done, except that any files created in between will be mis-dated. *Some* PCs will not retain post-1999 dates : see http://www.award.com/ . In addition, from a setting of 2000, a PC's clock may intermittently go wrong - "Time Dilation"; it seems rare, at worst, but reports are now convincing. The effect is that the clock date/time jumps at turn-on; the ROM BIOS boot firmware fails to deal correctly with an awkward RTC chip. A software fix has been developed (* Your family Elonex seemed OK, but it needs more testing *). There may also be problems with the CMOS RAM - have a backup. There may be "Latency" problems during rollover. Otherwise, something unpredictable may happen. I don't know about small computers other than DOS/Windows PCs. = GENERAL SOFTWARE = Some consquences of date-handling errors are fairly easy to foresee; but strange things can happen when numbers get unexpected values: program termination, program corruption, premature expiry/purging, negative interest, OAPs deemed infants or unborn, ... Harder to foresee has been the difficulty of finding and fixing everything beforehand. One can't tell yet what effort, time, and so on it will take to correct the data (and the resulting chain of mistakes) after it has been mis-processed. When existing software is edited to deal with the date problems, other, perhaps seeming quite independent, errors may be introduced. = SOME EXAMPLES = The standard Windows File Manager (3; 95) display has a cosmetic bug for files dated after 1999; there are corrected versions. { I have these. } Other programs may have display errors. During Y2k testing at a UK power station, a generator was tripped to off because of an overheating report caused by a date/time-arithmetic error. Credit cards with an expiry date of '00 or later have been rejected by some point-of-sale systems. In a Detroit supermarket, the computer system crashed every time a Y2k date was entered. Goods in UK stores have been machine-deemed by stock-control systems, in '97, to be well past their sell-by date of '00; and therefore scrapped. The Wanganui, NZ, court system, from 1998-01-01 until fixed 4 days later, could not set traffic offence trial dates after 1999 (2-year backstop!). A wine broker's computer 'updated' Chateau Margaux 1900 to Ch. M. 2000. A Leap-Day problem : laboratory systems at Papworth Hospital (UK) failed on 1996-02-29. A similar problem : At Tiwai Point in New Zealand, the fairly new control systems of an aluminium smelting plant could not handle the 366th day of 1996 - repair after overheating cost over a million NZ$ (news:comp.risks Digest #18.74). Exactly the same occurred, two hours later, in Tasmania. Another similar example : ESA's Ariane 501 rocket used the same software as the Ariane 4 series, but Ariane 5 uses a different trajectory; the guidance computer programs could not handle the larger numbers; so a big boom! A pending problem - the Global Positioning System (GPS) week rollover on 1999-08-21/22 - affects older receivers; some *may* fail for up to a week. The year 2000 will be Leap; not everyone knows that. (* DRVB's next (14th) birthday is in 2000. *) = SOME POSSIBLE CONSEQUENCES = It is feared by some people that there may be minor or even major disarrangements of society, where there is reliance on computerised processing and control. Remember that many systems rely on others. Your bank may be unable to operate for a while. Your bank may make errors. Your bank may fail as a business. Both suppliers and clients may let you down, in supply or payment. Wages/salary/fees/grant/loan/whatever may be delayed. As may bills. Gas, electricity, water, sewage, telephone, internet may fail. "Intelligent" locks may fail. Electronic engine controls in newer cars and other vehicles could fail. Public transport may fail. Emergency & medical services may be handicapped, and/or busy. Modern sources of entertainment may fail. The food and fuel distribution chains may be in trouble. Your pub or shop may close; or may stay permanently open ... Large-scale celebrations of rollover may become dangerous. Law and order could be affected, or fail. Failures, being predicable, may not be covered by insurance. Etc. Any system in which the full date is used or can be set is suspect. In some cases, emergency reversion to manual methods may work acceptably; in others, it may not. = SOME CRITICAL DATES = (taken some while ago from my Web site, many more are now in critdate.htm, q.v.) 1999-01-01 - Start of the last year of the 1900s. 1999-04-06 - Start of UK FY 1999-2000. 1999-08-11 - Cornish Solar Eclipse - a bit of "Light Relief" before 2000. 1999-08-21 - End of GPS Week 1023 @2400h, 10-bit field rollover (~2300h BST) : http://tycho.usno.navy.mil/gps.html, http://tycho.usno.navy.mil/gps_week.html . 1999-09-09 - Default "nonsense" date in many data-entry screens. 1999-09-23 - 99 days to year 2000. 1999-10-01 - USA's government fiscal Y2k starts, FY 2000. 1999-10-03 - 90 days to Year 2000 - 90 day intervals are common (& 60, 30). 1999-12-31 - Sometimes used as "Never Expires" date (IBM Tape ...). 1999-99-99 &c - a better "nonsense" or "special" date than Sept 9th. 2000-01-01 - THE YEAR 2000 starts. Saturday. One year to M3 & c21. 2000-##-## - Still 20th Century, but some will say 21st. 2000-02-29 - This valid date is not expected to occur by everyone - "LEAP DAY". 2000-03-01 - Some leap year errors may not have shown yesterday. 2000-08-04 - QEQM centenary. Consider also 2000-07-14. 2000-09--- - Certain consequences of over-celebration are appearing ... 2000-09-09 - Sometimes a "signal" date - cf. 1999-09-09 2000-12-31 - 366th day of year. 2001-01-01 - Third Millennium and Twenty-First Century start. ... = WHAT YOU SHOULD HAVE DONE (as at CINDI and ELSEWHERE) = Be careful not to do something that may need putting right when you're not there. In case of doubt, find a local professional (* or someone like Dom *) or leave well enough alone. But warn the "owners". Your computers should each have emergency floppy discs that they can boot from, into MSDOS (make these with SYS, and ensure that they carry a plain editor (e.g. TED) and other tools). You can boot from one of these (or, even better, from a DISKCOPY of one) to do the RTC tests, and on 2000/01/01. Allow for the possibility of licenced software being date-sensitive; it is conceivable that some might refuse to run after seeing a post-expiry date. You should initiate Year 2000 checking on all systems that you control, influence or use, now if not sooner. Also, of course, virus-checking, unless your machines are well isolated. There's now quite a bit of information on my Web site and linked from it ... In spreadsheet and database software, such as Excel, there may be options settable on date formats (e.g. FoxPro has "SET CENTURY ON/OFF") and on date windowing (i.e. assuming all dates are within a specified 100-year range, such as 1970..2069) - investigate these as soon as possible. It may well be worth correcting and optimising these before upgrading software, so that the data is correctly up-converted. Whenever you can, arrange to insert/store dates in full, in ISO 8-digit style as YYYY-MM-DD. Keep back-ups systematically and generously and safely; it may be necessary to repeat work. Where possible, test on isolated systems. Get incorrect systems replaced or remediated. Ensure anything new is compliant. = DATE SORTING = It's always best, if one can, to use the ISO-preferred order for 8-digit dates, YYYY-MM-DD rather than the American MM-DD-[YY]YY or the UK's normal DD-MM-[YY]YY. It is unambiguous (no-one uses [YY]YY-DD-MM), and sorting alphabetically is sorting chronologically. Don't refer to CCYY or to [CC]YY, as CC (century) can be misinterpreted - true CC is 99 years ahead of YY. The "date" 01/02/03 could mean anything, or at least it could mean any of 1 Feb '03, 2 Jan '03, 3 Feb '01 - in 1900s or 2000s - avoid YY-MM-DD. YYYYDDD also sorts correctly, but not YYDDD. Also, by the way, use the 24-hour clock, for reasons now obvious; if it can matter, remember the Time Zone, and consider using just GMT/UTC. = GENERAL PRECAUTIONS for 2000-01-01 = However little belief one may have in the predictions of doom, it seems to me wise to take, as insurance, *at* *least* such inexpensive precautions as one easily can - and to get family, friends, neighbours and dependents to do likewise. Arrange these before any shortages caused by others doing so. If things begin to look bad, hide most, but not all, supplies. Buy early for Christmas; don't rely on buying after it. In fact, don't rely, where it can be avoided, on everything working perfectly - either in early 2000 or at any other time. Have some potable water to hand. Have some emergency light and fuel available, plus normal full tanks. Have independent heating and/or warm clothes ready. Have the larder no less full of food, including storables such as rice, than its normal maximum; likewise fuel and other consumables; don't trust the fridge or freezer. Likewise have stocks of health products. Have at least your normal maximum of cash accessible, but not all kept on your person. Have paper copies of important records (bank, savings, ...); check before 2000, check again during and after 2000. Check insurances. Don't be flying (don't fly 1999-08-21/22 either), or reliant on public or private transport, or in a lift. Don't be in hospital. Be in a sensible place, near home - or so far from civilisation that you won't notice (visit IGB?); get home before Christmas; be able to stay there until things are again trustworthy. Avoid the USA. Avoid big parties. Close down and unplug delicate equipment from just before 2000 starts until power is trustworthy - PC, TV, Video, etc; controllers. Have spare batteries, including for the PC RTC/CMOS! Have something to do. During early 2000, monitor the mains supplies. Don't be the first to rely on anything which might have failed. Do the first PC start-ups in 2000 from floppy disc, and check the date. In addition, heed HMG recommendations. Note : many professionals will be called on to work extra time over the period; and many people will want to take extra time off. Note : Food expiry dates which are, or might be, after 2000 have added ambiguity. = SOME REFERENCE URLs = UseNet News Groups : news:comp.software.year-2000, news:comp.software.year-2000.tech, news:uk.tech.y2k, news:alt.talk.year2000, news:comp.risks (Digest; entertaining and worrying) JRS's own Web site : http://www.merlyn.demon.co.uk/ - date2000.htm, y2k_mfaq.txt, critdate.htm, miscdate.htm, test2000.htm, refs2000.htm Dave Eastabrook's : http://www.elmbronze.demon.co.uk/year2000/ Rick Cowles' site : Gone General and NG FAQ : http://www.cinderella.co.za/ Chris A's Mini-FAQ : http://www.cinderella.co.za/minifaq.txt Pam Hystad's FAQ : http://www.computerpro.com/~phystad/csy2kfaq.html Y2k FAQ (lengthy) : ftp://www.year2000.com/pub/year2000/y2kfaq.txt Microsoft Y2k FAQ : http://www.microsoft.com/y2k/2kfaq/2kfaq02.htm Food : http://www.merlyn.demon.co.uk/date2k-3.htm#Food A UK Magazine : Personal Computer World, Feb 1998, pp. 208-220; "Hands On", April 1999 ff. A US Magazine : Byte, July 1998, pp. 52-62. Other references are maintained on my refs2000.htm Web page, and at Dave E's - if you can't read those, you can't access the references on them either. === ENDS. 000197AF Web Home Page : http://www.merlyn.demon.co.uk/index.htm