Is there the ghost of a past
era in your PC?
A White Paper on PC/AT Year 2000 Compliance and Related Issues.
Author: James Ling, BSc (Hons)
1. More than just the tick of a clock.
Many recently assembled PCs exhibit an inability to pass to the year 2000 without operator intervention; others cannot operate with these dates at all. Those that provide support often do so at differing interface levels, resulting in various implications for the applications to which the PC may be put. Since this behavior is defined by the CMOS and BIOS components of the motherboard, it is commonly referred to as the 'PC year 2000 hardware problem'.
Technological issues surrounding the year 2000 manifest in a number of forms, not all of which are concerned with the PC hardware problem. Other devices with a concept of time including such things as security systems, safes, fax machines and timed entry systems must be investigated, as must systems that may interact with PCs such as factory shop floor 'clocking in' systems, digital cameras and Point of Sale equipment. PC software may manipulate dates in any number of ways internally, both in displayed sections and invisibly during processing. With large systems where more than one programmer has worked, compliant behavior may be restricted to only parts of the system, leaving perhaps a seldom used function to cause subtle, but disruptive behavior. Even software that has no immediately apparent use for the date may be sequencing operations based on 'stamp' values derived from the date and time or creating 'guaranteed' unique identifiers seeded from date values.
It is clear from just this short introduction that the potential disruption could be both widespread and come from unexpected sources, especially for the ill-prepared. Equally clear is that software problems present the greatest challenge to those tasked with ensuring Millennium Compliance. Software is vastly varied, both in purpose and quality. The sheer number of applications on a single PC, down to the simplest of utility programs, ensures that a vast amount of time and expense will be required simply to assess and if necessary trace the origins of each piece of software, and then to locate and approach the creators (if they still exist).
In contrast, although there is much discussion of (and unnecessary confusion about) the PC hardware problem, from a technical stand-point it is clearly defined. Nearly every PC that exhibits such a problem with the year 2000 is amendable at some level. The hardware problem has in some ways stolen the focus - perhaps because it is more easily understood and some what more tangible than issues with software. It is not that the hardware problem should be ignored, even compliant software cannot be expected to operate when given an invalid date, but simply that tools exist to both detect and fix problems with the hardware.
The remainder of this document attempts to clarify the PC year 2000 hardware problem. It describes the tools that are required to accurately assess the support provided by individual PCs and provides some guidance with the interpretation of the results of these tools and to how the different levels of support encountered may impact on PC use within your organization.
2. On the hard stuff
The PC hardware problem came about from a legacy of programming and digital electronic design practices of an era more than 10 years prior. It had for a long time been common place to store years on computers as only two digits, where at this time, storage space and execution time were costly resources. Unfortunately, and key to many of the year 2000 related problems, many of these design decisions have survived till the present.
Early PCs required the manual entry of the time and date each time they were started. The Operating System (OS.), typically MS-DOS, maintained these until the machine was turned off again. When the IBM PC-AT was introduced, the CMOS unit was added which includes a Real Time Clock (RTC.) that maintains the time and date between uses with a battery. This was, and still is, an off-the-shelf component that also permits the store
age of other machine state information in a small CMOS memory during the times that power is removed. When the CMOS was added, software calls were also introduced to the BIOS to retrieve the date and time from the CMOS RTC. After fetching the time and date at start-up many OS continue to maintain an independent clock.
The RTC itself has only a two-digit year field. The designers who allocated the use of the CMOS memory, with fortunate foresight, set aside a location to hold the missing century digits. Since this 'Century Byte' is not a part of the RTC, it is not updated automatically when the date rolls over to a new century (i.e. does not perform 'Active CMOS change over'). This change has to be performed by software. Until recently, this was done by the operator using the built-in BIOS setup software to specify the current century manually, however with the year 2000 still seemingly a good way off, BIOS implementers did not always respect the need.
Even with a well-behaved BIOS, this approach still means that whether turned on or off, after the end of December 31, 1999, every such PC will have an invalid date until reset by a suitably capable user, engineer or an intelligent software agent.
Only very recently, have many PCs become 'Millennium Compliant', however from one PC to another, this compliance extends to different levels in the hierarchy of methods that software might obtain the date from the system. A very few, if any, provide a compliant CMOS interface, some provide BIOS startup support, others full BIOS support. Depending on the application to which the PC is put., the lack or differences in support can be a significant issue.
Some PCs, due to faults in the CMOS or BIOS design even prevent a year 2000 or greater to be stored, if these machines are to be retained, special consideration needs to be given to the current and intended use of the machine. In some cases, with suitable patch software, an extended period of operation can be obtained -the success of this depends on application requirements since 'standard' patch software that maintains a valid CMOS date often cannot be used in these cases.
A millennium diagnostic tool for PC hardware issues should identify all of the levels of compliance', so as to allow a clear interpretation of the applications that are likely to be affected. The next section covers this in more detail.
3. Selecting a Millennium Diagnostic Tool
To obtain the clearest possible picture of the date based functionality of PC hardware with respect to millennium roll over; there are a number of tests, which must be performed by thorough diagnostic software. Although a great deal of this testing is still often performed manually it should be noted that to do this requires a good understanding of the issues involved, significant time, and the results for each PC typically applies only to the operating environment currently installed.
Listed and described below are the tests that should be performed through the use of a millennium diagnostic tool. It is also useful if additional tests are included to test some of the basic functionality of the CMOS Real Time Clock chip simply to ensure that a more fundamental hardware fault does not become misrepresented as a millennium issue.
It is important that a diagnostic tool should include a cold restart of the PC in order to be able to accurately report on some tests.
Century Byte Retention
This test will indicate that a date set beyond the year 2000 is both able to be placed into the CMOS, and that it can be retained when the machine is restarted. If it is not retained, then it is often unwanted intervention from the BIOS that causes this loss.
BIOS Change Over at Restart
Some 'Millennium Compliant' BIOS have a 'partial compliance' implementation that makes the necessary fix up to the CMOS date only when the machine is restarted. Should this kind of test be omitted from a diagnostic, it has the potential to confuse as to the capabilities of applications and operating systems software. This is especially true of legacy and specialist applications (such as data capture/ data logging).
BIOS Active Change Over
This is a test that the BIOS is able to actively (i.e. at run-time) change over from the year 1999 to the year 2000. This, if present in combination with the above restart support is the minimum preferred level of Millennium Compliance. With this level of support, most common software applications are catered for adequately.
CMOS Active Change Over
The CMOS of a PC is unlikely to advance the Century value without software intervention, but as the root of all time in a PC the CMOS has been accessed by software directly where the accuracy of time and date values has been considered of importance. Although software of this type tends to be the smaller set, and usually of a more specialist nature (data capture/ data logging and process control), it is often difficult to differentiate and so without this support your task of analyzing of a software system is made all the more difficult.
Leap Year Operation
Tests to ensure that the leap year compensation feature of the CMOS Real Time Clock supports (primarily) the year 2000 as a leap year. This is a requirement of the British Standards Institute document PD2000-2, and is not expected to fail for a PC CMOS device, however some unqualified reports of failure do exist.
4. Diagnostic Results Interpretation Tree.
As with many jobs, simply having the right tool is only one half of the task. Having collected results, they must be understood and a correct interpretation made. This section hopes to help with this. With some results it will be necessary to go on to find the requirements of your software systems operating on a PC, this is yet another area of compliance testing not covered by this document and in some cases one which can only be addressed by the software provider.
Starting at the top of the tree diagram, follow the branches based on the results obtained from a suitable Millennium Diagnostics Tool. Continue until a leaf (circle) is reached. Each leaf number corresponds to an annotation, which describes the compliant and/ or non-compliant behavior of the tested machine. This information is invaluable to a successful interpretation of application requirements.
1. This PC has severe problems with year 2000 operation. It may be necessary to replace the motherboard of the tested machine. While 'standard' patch software may be unable to fix a machine of this type, investigation of special patch versions produced by some vendors may provide some suitable level of compliance for a specified period beyond 2000.
2. A PC with the maximum possible support, presenting a valid date at the CMOS and therefore at all other interface levels. With compliant software it will present no change over problems without exception. This PC will conform to all hardware compliance specifications.
3. This is a typical result for an older PC (and unfortunately for a few not so old). Such a PC has no automatic support for the year 2000, but can still be used within the new millennium. It is the operator's responsibility to make the date change required after roll-over has occurred. This means that an invalid date will be held from January 1,2000 (00:00:00) until the clock is reset. Watch out for PCs that boot directly to date based operations such as billing or that operate continuously as file or remote information servers and data capture/ data logging units. Installation of patch software is required to provide automatic support for date change over and so satisfy compliance requirements such as the British Standards documents.
4. This PC requires the use of its BIOS software interface to produce a valid date. This should present few problems to software provided that the CMOS is never accessed directly. Be careful with custom and UNIX like Operating Systems (OS.) that may obtain the date and time from the CMOS as they start. These OS cannot run with a valid date on the tested PC without a hardware or OS native patch. The CMOS century byte will not be valid from the year 2000. (Note that in this case it is also possible that the layout of CMOS memory may be non-standard. Although unlikely, this would make a fix to this PC non-viable and a replacement would be required.)
5. Such a PC will provide a valid date through the BIOS software interface at all times, and will provide a valid date from the CMOS also, but only once roll-over has occurred and has been read via the BIOS at least once. There is a potential window for error initially after the year 2000 arrives. Operating Systems that obtain the date direct from the CMOS and not via the BIOS will not automatically receive a valid date, but can continue to be used once the CMOS has been corrected manually via the Setup. Alternatively a hardware or OS native patch could make the process entirely automatic.
6. This has become a common configuration for many 'Millennium Compliant' PCs sold recently. The BIOS will correct an invalid CMOS date at restart, but makes no further attempt to correct the date at run-time, even if BIOS software calls are used. Such a PC relies on the Operating System (OS.) to maintain its own time and date and for the applications software in turn to obtain dates from the OS. when set to execute over the new year period. This level of support may not be sufficient for some legacy (DOS, Windows 3.x) applications used in this way. If the PC can be turned off while roll-over occurs it will not present problems. (Note that millennium compliance test software that does not include a restart test will show this PC as having no compliance.)
7. The tested PC offers full BIOS support for the year 2000, correcting an invalid CMOS date both at restart and at run-time. For most applications this machine will present no compliance problems. Only software that makes direct access to the CMOS will be affected, and only if the PC is executing over the millennium new year period - this typically encompasses only a small set of specialist and embedded applications such as data capture/ data logging or process control. If an 'active CMOS' is required, a subset of the various year 2000 patches can provide this additional support - check with the vendor of the patch software.
5. To fix or not to fix.
Both DOS and Windows 3.x software has the potential to make BIOS calls or direct references to the CMOS clock. Some favorite applications may well have made the migration to Windows 95. To be absolutely confident about the integrity of the dates obtained by such applications, it may be simpler and less costly to perform a 'blind' year 2000 fix of all PCs rather than to investigate. This approach reduces the potential failure set to an absolute minimum, typically zero. Of the rarer PCs with severe year 2000 support problems, provided critical systems have been tested, post-millennium support can be isolated to at most, a few machines. A clear understanding of the interactions within a system as a whole will help to access if such an approach can be taken. Saving time is likely to be critical since software system must then be tested for year 2000 date handling.
Flash BIOS upgrades are sometimes offered as a solution. This is a facility incorporated onto some PC motherboards, which allows the replacement of the BIOS code without removing the chip. However it is extremely important that the correct BIOS version is used as many have minor revisions designed to cope with specific motherboard idiosyncrasies. This makes flash upgrades potentially dangerous to perform and may result in far more subtle problems with more fundamental and crucial PC operations. Of course, a successful upgrade may still only provide a certain level of support; this must then be reassessed.
Upgrading hardware to the latest 'millennium compliant' PCs while seemingly a valid path can introduce yet further frustrations. Changing to a faster processor alone may cause software incompatibility problems, as was recently seen by users of a popular network operating system. A change of installed operating system can also affect the ability to use favorite applications. Additionally, new ATX PC designs mean that a simple
motherboard change is not an upgrade path on its own, requiring new case/ power supply unit, keyboard and mouse. Spending time and money tailoring systems and retraining staff is perhaps not the best way to approach the year 2000 if the requirement does not truly exist. Finally, remember that if new hardware is purchased between now and the millennium it too should be tested to determine the true level of compliance to ensure that it really is suitable for your requirements,
6. Who is to blame for a lack of support in the CMOS?
Simply, nobody. It is not possible to attribute blame for the lack of 'Active CMOS Support'. The manufacturers of the CMOS Real Time Clock devices have never claimed that their products support any more than a two digit year (and can provide product data sheets to prove this). This is completely permissible, even under the British Standard Institute's PD2000-2 guidelines. Under these guidelines, an inference rule may be used to obtain the century from a two digit year (for example, years 00-79 are to represent 2000-2079, 80-99 are to represent 1980-1999).
Similarly, the engineers who chose to place an explicit century value in the CMOS memory, can argue that this data 'belongs' to the BIOS and so therefore the only valid way to read it is to obtain it via an appropriate BIOS call (at which point a fully compliant BIOS can correct it).
Beyond this, a non-compliant BIOS is of course the responsibility of it's implement and any such organization 'worth it's salt' will already have taken measures to address this for new products, although it is more unlikely that there will be support for old models.
7. Maintaining compliance.
A set of guidelines should be drawn up by an organization to ensure that compliance is maintained when new hardware (PCs and other devices) or software is purchased. It is wise to test all new products regardless of the guarantees provided.
Choose a suitable and thorough millennium diagnostic tool for the examination of new PC hardware. It should not be assumed that all new purchases will be compliant. There may even be a surplus of unwanted or discarded stock that will try to find a market.
8. Formulating a statement of compliance.
If you are involved in the manufacture or supply of PCs, you may have to produce a formal statement of compliance for a customer. Since you cannot be sure of the use to which the machine will be put, it is important to indicate the level of compliance that you are promising to the customer and under what conditions this level of compliance is available. If a patch is included with the machine then it should again be clear that certain levels of compliance are available only while the patch is in place. You may choose to restrict the promise of compliance to only to a specific hardware and pre-installed operating system configuration. Discuss the wording of such a statement with your legal advisors.
9. Telepathic Software Tools.
Some vendors provide tools that claim to provide listings of millennium compliant or non-compliant software installed on a PC. The automated analysis of software packages is potentially misleading and wide open to error.
Such automated analysis typically takes one of the following forms; analysis of data files in common formats, passive analysis via a database of known applications or active analysis that inspects program code either in or out of execution.
Such tools can operate only with known data formats and will not be able to see past various forms of encryption or compression applied to either data files or to executables. Further, if a two-digit year is in use, this alone does not imply that a program does not address millennium issues for it is perfectly acceptable to use an inference rule to decide the century portion of the year.
Where a database driven approach is used, questions move to the completeness and accuracy of the database. Who performed the analysis for the database? With the extreme size and complexity of many programs, how can anyone be sure that all possible execution paths have been explored? Does the analyzer and database differentiate correctly between program versions and revisions?
Further questions arise with active analysis. Without knowledge of the purpose of a code section, how can an analyzing tool be sure of the compliance or non-compliance of the program? What differentiates code that manipulates dates from other program sections? What about macrocode or interpreted languages (BASIC, Java etc.) - the boundary between what is program and what is data, is seldom clear.
At best these tools offer a list which can be used to compare with perhaps a list of your own findings. These lists become particularly dangerous when temptation makes them a singular definition of the state of a machine's software.
10. Considerations of analysis projects.
This section gives a cursory glance at the wider scope of ensuring millennium compliance. It should not to be taken as a description of how best to manage your organization's year 2000 compliance efforts. However, the discussion highlights a great number of areas that require attention, and in doing this it is hoped that it can be an assistance as either a starting point, or to perhaps remind of items that might otherwise have become overlooked;
With the millennium now so very close it is important to establish the available time frame during which you can investigate, identify and remedy any shortcomings. Sooner is truly better than later as demand for products and services will increase (and probably the prices too) nearer to the year 2000.
When deciding the time frame be sure not to forget any predictive elements in your software systems, solutions if required will need to be in place before these predictive calculations can break down, not December 31, 1999. For bespoke systems in particular, approach your supplier, as identification of any software changes required, the time to make those changes, and the down time required for installation, all must be considered. They may also be dealing with systems for other organizations as well as new development.
Predictive calculations can occur in many systems, two disparate examples of which are automated stock control systems and management information systems. An insurance company in the USA discovered problems with their software in January of last year (1996) but not until serious damage had been done. Throughout 1995 active policies were marked to be deleted if there was no further activity by a date 5 years in advance, unfortunately the software stored a year of zero to represent the year 2000. A great many policies were quietly deleted because they had appeared to have been inactive for over 95 years. (Source: Solace Consultancy Services Ltd.)
Within your own organizational scope, note every PC and electronic device within your organization. Take more than a cursory glance in each office space, even something as simple as a wall clock/ calendar will look silly if the century part of the year is preset.
Some devices may appear to have no use for the century and show only a two digit year field, a year of '00' to represent the year 2000 may seem quite acceptable in the context of their use, but if device behavior is dependent on the day of the week, and the device firmware uses a commonly published algorithm to calculate that day of the week, it will need to assume a century internally. Since January 1, 1900 was a Monday, but January 1,2000 is a Saturday, day of week functionality has the potential to appear operational until Thursday January 6,2000 when the two-day skew would signal weekend behavior. (Think of the chaos for an automatic door lock.)
For PCs, evaluate the procedures used over new year periods and the proposed or possible use of machines over the transition from 1999 to 2000. Will all machines in your organization be left on for an automated back up, or will they all be turned off? If they are to be turned off, is there any way to guarantee that this will be the case? It is not uncommon for the monitor to be turned off, but not the PC. Will anyone be working over the holiday period or have access to PCs, even for recreational purposes? Remember also, that this will be at a time of a great deal of festivity and in the last hours of business, the minds of employees will not be as focused on procedure as at other times or even other new years.
Of course some PCs must remain active at all times, and in some applications, to shut them down unexpectedly, even for a short period would be a costly exercise that is best avoided. Back-up hardware would be of no help here if the back up has identical problems when switched in. Do not over-look such back-up systems.
Many PCs are configured to boot directly to an application, which may then at the start of the day's business commence billing or other operations, performing direct updates to company records. These PCs obviously must warrant particular attention, as the potential for disruption is that much greater after the millennium.
Find out what Operating Systems (OS.) are in use within your organization and if possible, establish how they obtain the date. Maybe you can try getting a written statement of compliance from your OS vendor, and ask if the promised compliance covers only the operation of the OS, or if it covers invalid date fix up for the PC hardware. Do not forget of course that year 2000 patch software may well provide sufficient support to satisfy your requirements and avoid unwanted time and cost for investigation.
Check your pre-printed stationery, particularly less frequently used forms, does your organization still have stationery items with dates containing an already entered '19'?
Moving outside of your direct organizational scope, it could be advisable to check the readiness of the other organizations on which your business operations depend. For manufacturing, are your suppliers of critical components and raw materials confident that they will not interrupt the flow of materials? This could be particularly important if the processes involved keep deliberately low levels of reserve materials, operating a JIT. (Just In Time) relationship with suppliers.
Financial service providers and insurance companies should perhaps be approached to be sure that their operations and cover will also remain unaffected.
Returning to PCs, some ISPs (Internet Service Providers) and their respective software 'correct' the PC's clock when you log in. Should this intervention exist, an incorrect date could undo all the hard work of making a PC compliant.
Finally, if your operations generate data that is then accessed remotely (electronically) by other organizations and this has some kind of direct or implied date dependency, ensure that problems that might be encountered by these organizations can be unequivocally demonstrated to have occurred outside the scope of your control.
All trademarked names identified in this document are acknowledged to their respective holders.
A DEFINITION OF YEAR 2000 CONFORMITY REQUIREMENTS
Preamble to the Summer 1998 amendment
BSI DISC originally published PD2000-1 in January 1997 and it has been widely adopted. A review of the document was conducted by the responsible committee (BDD/1/3) in the spring of 1998 taking into account comments received. The committee considered that amendments to the fundamental conformity requirements were neither necessary nor desirable. The Definition and the four Rules are unchanged but, to add value to the document and aid its interpretation, the Amplification sections have been amended. This document, PD2000-1:1998, replaces the previous version of PD2000-1 but does not change its requirements. An additional document PD2000-4, entitled "PD2000-1 in Action" will provide further information on PD2000-1:1998 together with information on its use.
Paragraph numbers have been enhanced in the Amplification section to aid referencing and substantial revisions to the document are indicated by side lines against the changed text.
Introduction
This document addresses what is commonly known as Year 2000 conformity (also sometimes known as century or millennium compliance). It provides a definition of this expression and requirements that must be satisfied in equipment and products which use dates and times.
It has been prepared by British Standards Institution committee BDD/1/3 in response to demand from UK industry, commerce and the public sector. It is the result of work from the following bodies whose contributions are gratefully acknowledged: BT, Cap Gemini, CCTA, PricewaterhouseCoopers, Halberstam Elias, ICL, National Health Service, National Westminster Bank. Additionally, BSI DISC acknowledges the support of the Electronics and Information Industries Forum (EIIF), Action 2000, Taskforce 2000 and Digital Equipment as well as the original bodies for their participation in the review of this document. BSI DISC would also like to thank the following organizations for their support and encouragement in the development of this definition: Barclays Bank, British Airways, Cambridgeshire County Council, Computer Software Services Association, Department of Health, Ernst & Young, Federation of Small Businesses, IBM, ICI, National Power, Paymaster Agency, Prudential Assurance, Reuters, Tesco Stores.
While every care has been taken in developing this document, the contributing organizations accept no liability for any loss or damage caused, arising directly or indirectly, in connection with reliance on its contents except to the extent that such liability may not be excluded at law. Independent legal advice should be sought by any person or organization intending to enter into a contractual commitment relating to Year 2000 conformity requirements.
This entire document or the Definition section (including the four Rules) may be freely copied provided that the text is reproduced in full, the source acknowledged and the reference number of this document is quoted. It is recommended that the Amplification section be included. References to "PD2000-1:1998" shall be interpreted as meaning the entire document.
THE DEFINITION
Year 2000 conformity shall mean that neither performance nor functionality is affected by dates prior to, during and after the year 2000. In particular:
Rule I No value for current date will cause any interruption in operation. Rule 2 Date-based functionality must behave consistently for dates prior to, during and after year 2000. Rule 3 In all interfaces and data storage, the century in any date must be specified either explicitly or by unambiguous algorithms or inference rules. Rule 4 Year 2000 must be recognized as a leap year.
AMPLIFICATION OF THE DEFINITION AND RULES
I General Explanation
I.I Problems can arise from some means of representing dates in computer equipment and products and from date-logic embedded in purchased goods or services, as the year 2000 approaches and during and after that year. As a result, equipment or products, including embedded control logic, may fail completely, malfunction or cause data to be corrupted. 1.2 To avoid such problems, organizations must check, and modify if necessary, internally produced equipment and products and similarly check externally supplied equipment and products with their suppliers. The purpose of this document is to allow such checks to be made on a basis of common understanding.
1.3 Where checks are made with external suppliers, care should be taken to distinguish between claims of conformity and the ability to demonstrate conformity.
2 Amplification of the definition
2.1 PD2000-1 (all editions) is solely concerned with the performance and functionality of a single version, release or system. It does not address differences in performance or functionality between different versions, releases or systems. 2.2 Variations in performance immeasurably small in the context of use do not make a version, release or system non-conformant.
3 Amplification of theRules
3.1 Rule I
3.1.1 This rule is sometimes known as general integrity.
3.1.2 If this requirement is satisfied, roll-over between all significant time demarcations (e.g. days, months, years, centuries) will be performed correctly.
3.1.3 Current date means today's date as known to the equipment or product, i.e. the actual date of operation [NOTE - this refers to normal operation and does not prevent testing.] 3.2 Rule 2
3.2.1 This rule is sometimes known as date integrity.
3.2.2 This rule means that all equipment and products must calculate, manipulate and represent dates correctly for the purposes for which they were intended.
3.2.3 The meaning of functionality includes both processes and the results of those processes.
3.2.4 If desired, a reference point for date values and calculations may be added by organizations; e.g. as defined by the Gregorian calendar.
3.2.5 No equipment or product shall use particular date values for special meanings; e.g. "99" to signify "no end value" or "end of file" or "00" to mean "not applicable" or "beginning of file" unless the values in question lie outside its possible date range.
3.3 Rule 3
3.3.1 This rule is sometimes known as explicit/implicit century.
3.3.2 It covers two general approaches:
(a) explicit representation of the year in dates: e.g. by using four digits or by including a century indicator. In this case, a reference may be inserted (e.g. 4-digit years as allowed by ISO 8601:1988) and it may be necessary to allow for exceptions where domain-specific standards (e.g. standards relating to Electronic Data Interchange, Automatic Teller Machines or Bankers Automated Clearing Services) should have precedence.
(b) the use of inference rules: e.g. two-digit years with a value greater than 50 imply 19xx, those with a value equal to or less than 50 imply 20xx. Rules for century inference as a whole must apply to all contexts, in which the date is used, although different inference rules may apply to different date sets. Where any date element is represented without a century, the correct century shall be unambiguous for all manipulations involving that element.
3.4 Rule 4
3.4.1 A leap year is defined in ISO 8601:1988 (amended in 1991) as follows: "year, leap: In the Gregorian calendar, a year which has 366 days. A leap year is a year whose number is divisible by four an integral number of times, except that if it is a centennial year it shall be divisible by four hundred an integral number of times."
3.4.2 Thus, for example, 2000 is a leap year but 1900 is not.
4 General Notes
4.1 For Rules I and 2 in particular, it is recommended that the allowable ranges for values of current date and dates to be manipulated be documented, recognizing that all systems have some limitation on the valid date ranges. The ranges may relate to one or more of the feasible life spans of equipment or products or the span of dates required to be represented by the organization's business processes.
4.2 Tests for specifically critical dates may also be added (e.g. for leap years, end of year, etc.). Organizations may wish to append additional material in support of local requirements.
4.3 Where the term "century" is used, clear distinction should be made between the "value''denoting the century (e.g. 20th) and its representation in dates (e.g. 19xx); similarly, 21st and 20xx.
Should you be concerned by the Year 2000 problem? You should!
/ want my computer to work correctly and receive correct date and date-calculated output. Why isn't this possible on a non-Year 2000 compliant system?
To answer this, I'm going to get a bit technical. In order to understand the complexities of the year 2000 problem, you first have to grasp the hierarchy of PC component layering and how date information passes through your computer. There are basically four layers. It might make it easier if you think of these as four building blocks:
Block One - Hardware
Your bios must be able to recognize and handle 00 as 2000 and as a valid number. The CMOS must be able to retain the RTC (Real Time Clock) date and time when the PC is turned off.Block Two - OS (Operating System)
Upon system start up, the OS requests the date and time from the BIOS. Most network PC's take their date and time from the servers OS clock. So even if your PC is compliant, you server must also be compliant for your date and time to be correct.Block Three - COTS (Commercial Off The Shelf software)
Vendor applications take date and time information from the OS clock. Some take it directly from the hardware layer (the RTC)Block Four - Custom APPS
There is no standard or "only" way to get a time/date stamp, report headings, accounting dates. This information can come from the OS or the Hardware. To further complicate matters, this information can come from Your PC's OS, the Servers OS or from a 3rd source.All of these layers or blocks MUST be compliant for your data to be useable in the Year 2000.
Will going into all of my end user applications data (spreadsheets, databases etc) and changing the century format from YY to YYYY correct the problem?
Unfortunately, no. Applications on opening get their date and time instructions from the OS which depend on the Hardware layer. If the hardware sets itself to 1980 or 1900, your end user applications will be reverted to those dates, albeit with a nifty new YYYY format. There are no shortcuts, no silver bullets. The solution must address all of the component layers to correct the Year 2000 problem.
On the other hand, applications may actually RESET the Operating system date upon exit if the application wasn't happy with the Post 2000 date. It might be the applications highest acceptable date (2027), or some other unrelated date. A recent example that comes to mind occurred this week in our Y2k divisions' test lab and demonstrates this ability of applications to change the OS system clock. A Win95 machine set to June II, 2038. Quickbooks for Windows has an upper date of 2027 and insisted the date was 1-1-70 but did not alter the OS on exit. How do you calculate a 30-year loan if your Software won't go past the next 27?
Running older legacy programs in a DOS shell, such as Quicken for DOS, presents much more serious errors. Entering an OS date of 203 8 returned a number of major problems - the first being that Quicken reads anything after 2000 as 6/11 '00 rather than 6/11/00. This causes difficulty with import and export functions, especially since Quickbooks for Windows sees the '00 as 1900, the opposite of quicken. The most notable glitch was upon exit of Quicken, when the operating system date set itself June 11,2016 Repeated experiments showed an OS date of 2005,1994,1983 and 2027. This was a repeatable cycle. In three different tests, the application corrupted the OS date. These findings seek to illustrate the changes many non-compliant software applications can have on the OS.
According to the Intuit Quicken web-site, they are aware of the problem and plan to remove the upper date limit in future versions. "However, the current implementation should not cause any significant practical problems since there is no current need to enter transactions that far in the future." This is the same nearsighted logic that created our current year 2000 problems. The Software Industry must seek to eliminate all software date limitations in order to avoid this same problem in the future.
Won't getting a new BIOS solve the problem?
A new BIOS will solve your BIOS problem. Maybe. If you flash the BIOS without knowing what the board manufacturers have done to tweak performance you could render your computer unusable. If you do manage to upgrade your BIOS successfully, that does not mean the other layers (OS and Software) are automatically fixed. Windows 3.11 and 95, even with a perfectly working BIOS, might see the year 2000 in file manager as ;0 or sometimes as %0. Upgrading the BIOS does not rewrite the software or OS to YYYY or to handle other internal Year 2000 issues. A compliant BIOS does not promise a compliant system. It does mean that you now have a foundation to work on. After that, any software redemption that you do will at least be able to run on your hardware.
By fixing the BIOS does that mean I've solved the RTC (real time clock) problem?
The BIOS receives its date/time from the RTC and retains the date and time when the PC is turned on. The CMOS retains the RTC date and time while the PC is turned off. One method has been suggested that after you "fix" the BIOS, you reset the date and time every time you turn your PC on - this is a work around for a faulty RTC but it by no means solves the problem. Since the RTC gives its instructions to the BIOS, to have solved the hardware problem, the RTC must retain the date when the PC is turned off. For any programs that get their time/date information directly from the RTC rather than the BIOS or OS, this is not a solution.
So the RTC needs to be replaced in order to solve the problem?
The vast majority of machines do not pass the RTC test. Some BIOS will correct the century date on it's way to the application. Most software takes its date from the OS or the BIOS and not the RTC layer. The question then is - does yours? If your BIOS passes but your RTC does not, that means the BIOS was able to intervene and correct the date problem. If your software looks directly at the RTC layer, you will NOT be compliant. Your machine will run, your OS may look fine, but the data from the application in question will be corrupt.
What can I do if I have applications that interrogate the RTC for date information?
Replace the software with one that is not RTC dependant, rewrite the application to pull the information from the OS or BIOS or replace all the ROTC's in all systems that will access that data.
Which chips require replacement and how do I go about that?
You have to test the machine in order to determine compliance. Because of the sheer number of chip makers, the same PC's bought at the same time from the same store may not have identical chips in them. One may be compliant and one may not. So you've determined that some of your ROTC's need to be replaced - now what? The first thing to do is more research: Is the chip manufacturer still in business? Do they have a compliant replacement? Does it fit into your motherboard? Does your motherboard support the new chip? Does the old BIOS recognize the new chip? If all of these criteria are met, chip replacement is possible. Otherwise, motherboard or system replacement with a certified "Y2k OK" machine is my recommendation.
A major oil company has discovered that they need to replace chips for their Trans-pacific pipeline. In addition to the problems of hardware change outs at 10,000 feet below sea level, they discovered that the new compliant chips didn't fit the old motherboards and the replacement boards didn't fit the old valves! In this instance they opted to replace the software.
How can I make sure that this entire Year 2000 issue isn't a goofy fantasy or a hoax inspired by selfish motivations?
The facts are simple: The computer applications and the computers themselves upon which we rely are broken. Anyone claiming that the Year 2000 problem is not real has an obligation to explain why corporations and governments are spending billions of dollars on a nonexistent problem. The problems associated with the Year 2000 date change are testable, repeatable and consistent. The deadline (January 1st, 2000) is immovable and the computer industry has a poor reputation for delivering systems on time. The alternative to addressing this problem will be for many companies to close their doors. No hype or exaggeration is necessary; the news is bad enough without embellishment.
What efforts are you making to assist the community to achieve year 2000 compliance beyond being a paid consultant?
I am committed to raising awareness of the Year 2000 problem through seminars. Task Forces and Special Interest Groups. I am starting an Alamo PC Year 2000 Special Interest Group. I also am working closely with the San Antonio Safety Council, and other community groups.
I have a small company with new software and brand new Pentium computers. Why should I worry about Y2k compliance?
Large corporations with old software aren't the only ones which are affected by the Year 2000 problem. Small companies running Windows 95 and/or Windows NT should pay close attention to a recent announcement by Microsoft. They have finally admitted publicly that there are Year 2000 problems in Windows 95, Windows NT and the Internet Explorer - despite very strong statements made over the past two years that Microsoft's products were not affected by "Y2K. For a multitude of reasons, your new Pentium chip may not be as complaint as the price tag led you to beleive.
How much time do I have before I have to start on my Year 2000 efforts?
None. That is a scary thought - ignoring is has scarier consequences. Denial of truth always has a consequence. The time taken to convince ourselves of the severity of the problem was stolen from the time necessary to implement the solution. A shortage of time is something we now have to live with.
Because the results of the Year 2000 will not be fully evident until the change has already occurred, it is absolutely necessary to begin efforts as soon as possible.
The Year 2000 problem was when created when it was decided to make compromises in quality in order to save space, money and time. It was perpetuated when it was decided that what was done yesterday was good enough for today and it was deemed unnecessary to evaluate the inevitable consequences of cutting comers on quality. It was exacerbated by people who scoffed at warnings which were later proven true. It was turned into a crisis those who left it until the last moment. It will be solved by each of us, only as we begin to treat it with the respect it deserves.
What are your plans for the Year 2000 Special Interest Group?
Our mission is to provide a forum where individuals and businesses can work together as partners, mentors and instruments of change to help our community understand and successfully resolve the challenges of the Year 2000. This Special Interest group is open to all Alamo PC users and will be at the Resource Center on the Third Monday of every month from 7-9p.m. Alamopc.org/y2k for coming issues, events and activities.
Dr. Lila York has been a leader in the IT community for over 12 years. She has consistently been in the forefront of new technology and has recently taken a lead role in the development and implementation of Year 2000 strategies and now brings her expertise to San Antonio as the Director of Special Projects, Southwest Stars Corporation. She is a voting Member of the IEEE and a member of the American Telemedicine Association. As Y2K consultants, Sffnmwesf Stars Corporation offer services, staffing and project oversight in the areas of testing, training, remediation and implementation throughout the entire Year 2000 compliance process. She can be contacted with questions or comments at lilayork@swstars. corn