Year 2000 Compliance Guidance Notes for the Fire Service
Research Report Number 10/97
J A Harwood
It is hoped that by now all Local Authority Fire brigades have been alerted to the potential hazard of the so-called "Millennium Time Bomb" and are taking precautionary measures. However such is the concern, particularly for emergency services, that it has been thought worthwhile for the Home Office to provide these notes, based on work undertaken by the Fire Research and Development Group, Mentis Management Consultants Ltd and the Police Information Technology Organisation, to supplement the guidance which brigades may already have had and to provide a check list..
A major task is the identification of where problems might arise, and this will depend on the extent and timing of individual brigades investment in IT. In consequence, all that central guidance can achieve is to emphasise the problem and to alert brigades both to the need to tackle it vigourously and to advise the public of their need to make assessments of IT based equipment, for example, in relation to automatic fire alarms and sprinklers, but particularly where the risk of malfunction may be very high such as in the petrochemical industry. CONTENTS
|2.1||Pinpointing the Year 2000 Problem|
|3.||RESPONSIBILITIES AND MANAGEMENT|
|4.||YEAR 2000 COMPLIANCE ACTION PLAN|
|4.2||Assessing the situation|
|4.3||Evaluating the options|
|4.4||By-products and additional benefits|
|4.5||Planning to tackle the problem|
|4.6||Managing the Change Programme|
|5.||COMMENTARY ON SPECIFIC ISSUES|
|5.1||Relations with others|
|1.||Hardware/Platform risk assessment|
|2.||Checklist for action (computer system)|
|3.||Checklist for action (embedded systems)|
|4.||British standards institution (BSI) definition|
1. MANAGEMENT SUMMARY
|Isnt This Just a Technical Issue?||No. Whilst the problem originates in the way technology has been designed and is used,
the scale of the risk and the potential action required will necessitate it being
addressed by a co-ordinated management and technical response.
A modern brigade depends on computer systems and high-speed telecommunications to provide essential support to ensure operational effectiveness and run administrative systems efficiently and effectively. Within these systems dates are often essential triggers for action, such as the creation of rosters, generating alerts in planning systems or signalling forward dates for training. If these applications start to fail and public services are affected, it will not be a credible management response to say "it was just a technical issue".
If devices with embedded systems, such as time-clocks, electronic locks and alarms malfunction or fail completely at the start of the new millennium, the resulting chaos will be an operational and business problem; it is up to operational and business people to ensure that the risks are minimised.
The problem will cross functional and operational boundaries. Brigades will need to plan their actions according to priorities agreed across these, as resources will undoubtedly be stretched.
|How Big is the Problem?||The scale of the problem will vary from brigade to brigade, but evidence from commerce
and industry suggests that its resolution may be expensive and time consuming. As it
affects all systems in parallel during a short time period, it may represent the largest
IT project a brigade has ever undertaken.
A major independent research organisation, The Gartner Group, estimates that 90% of all systems will be affected in some way by Year 2000 problems. Although it is likely that fire service systems will not be the hardest hit, any major malfunction could have a major impact on public confidence in the service.
As regards embedded systems, brigades are potentially very exposed, particularly with regard to automatic fire alarm systems. Appendix 4 to the Notes sets out a list (far from exhaustive) of typical everyday electronic devices which may contain date-dependent processors
It is possible that brigades will have to divert resources from other projects to solve Year 2000 problems As the millennium approaches, external resources - such as consultants and contractors - will become scarcer. In some circumstances brigades may consider early replacement of existing systems, but a careful and conservative assessment of the risks of any malfunction or delay in implementation must be made.
|When Will it Arise?||Brigades have an ever increasing inventory of computer programs and systems, and all
must be reviewed and altered if necessary to avoid errors, operational inefficiencies and
putting the public at risk. There is very little time available to solve the problem, so
clearly the earlier a brigade begins to work on its solutions the more chance it has of
For systems which store forward dates, problems may start to manifest themselves as soon as dates after the end of this century are used or implied.
| Can We Fix the Problem by Buying Off-the-Shelf Software?
||Unfortunately there is no universal solution which can be applied. This Notes shows
how a brigade can mobilise its resources in an effective way to tackle the problem, and
ensure that alternative courses of action are thoroughly and rapidly evaluated having
regard to practicality, robustness and affordability.
In some areas off the shelf solutions may be a possibility, but each brigade must undertake the following actions:
These Notes provide proposals for undertaking the tasks outline above.
|External Factors||Fixing the problems in-house may be only part of the task. Brigades may have external
systems and communications links to many outside organisations - service providers,
business collaborators and others. To tackle the issue completely, these linkages and the
risks inherent in them need also to be addressed.
Another possibility which needs to be considered, or may be under consideration, is whether brigades may be able to gain from selective collaborations with each other to tackle common problems. This may be particularly appropriate where several brigades use the same system or facility from a single supplier.
|Management Arrangements||In tackling the Year 2000 problem, the Notes recommend a structure where:
|Conclusion||A seemingly simple problem which has the capability to bring major corporations to their knees requires serious and concerted senior management commitment, thorough investigation and careful planning. Taking action immediately should allow the problem to be managed, although significant redeployment of manpower and financial resource may be necessary.|
2.1 Pinpointing the Year 2000 Problem
|Exactly what is the problem?||The problem is that we talk about, and store, date information in a convenient
shorthand form. We use 01/12/96, knowing we mean 01/12/1996. However computers only know
what they are told, and therefore cannot distinguish between the dates 01/12/1996 and
01/12/2096 and 01/12/1896 unless programmed to require input of the four-digit year. Many
programs written over the last several decades used only the last two digits in order to
save storage space. Equally, they will not treat the year 2000 as a leap year.
This will cause problems with many computer systems which use date information and exchange it with other systems. Whilst at first glance this seems an easy problem to fix, it isn't. It will also affect computers outside the mainstream of IT, such as telephone switchboards, communications network equipment and labour time-clocks.
|Obstacles to fixing the problem||There are many popular assertions about the Year 2000 issue, which fail to recognise
the type and nature of obstacles which will get in the way of a smooth solution to the
problem, such as:
"The problem could be easily fixed if each organisation only had a few systems and programs".
The problem is they may have hundreds or thousands.
"The problem would not be too bad if dates were always treated in the same way for input, storage, analysis and reporting".
The problem is that one single computer program may handle dates in several different ways.
"We shall be able to assess the problem after we have looked at the documentation".
The problem is that most organisations had no standard way of recording date information and documentation of many systems is woefully out of date, or non existent.
"The problem should not be too bad because weve only bought packaged software in recent years".
What organisations often dont realise is that many of today's packages were originally designed a decade or more ago - still in the age of shorthand dates. Additionally each package probably treats dates in different ways, so when information is swapped or compared between systems, even after being fixed by the supplier, there may still be problems. If anyone has done anything to them - programmed bespoke interfaces to other systems for instance - these add-ons could themselves not handle dates properly, and are probably not covered by any assurances the supplier may give.
|Action is urgent||You cannot wait - date problems are happening to businesses now. Some organisations
have already begun to experience date difficulties. For example, consider what is (or
was!) the earliest time at which your brigade will need to enter a date for something
which will happen after 1999?
The problem has been subject to considerable hype in the media. But for some organisations, it is moving rapidly from hype to reality and will quickly turn into a corporate threat, unless action is taken.
|Purpose of these Notes||This document provides a general overview which can be used by senior managers to assess the impact that Year 2000 computer system issues will have on their own brigade, including guidance for a consistent systematic approach to the Year 2000 problem;|
|Coverage||The Notes concentrate on all types of operational and administrative computer systems,
personal, departmental and brigade-wide. Embedded date-dependent electronic systems in
technical devices such as wireless communications systems, telephone logging systems,
time-clocks or CCTV recorders, which may have their own in-built processors, are not
covered in specific detail, but additional guidance is given to tackling this area.
Following the proposals will facilitate the development of local answers to the question "How vulnerable to disruption are the public services provided by the brigade as a result of computer system malfunction caused by Year 2000 date problems?"
It will also suggests a framework within which the necessary actions can be taken to eliminate the main vulnerabilities and minimise the risks from the date change.
It is clear that that the structure proposed in these Notes does not represent the only viable way of approaching the Year 2000 issue. Some brigades may have existing projects/ programmes under way. In this instance, it is hoped that the contents of the Notes will constitute a checklist and "sidelight" against which the structures set up can be validated and improved if necessary.
3. RESPONSIBILITIES AND MANAGEMENT
|Ownership and responsibility||This section of the Notes considers the roles and responsibilities of officers and
managers within fire service brigades for addressing the Year 2000 problem. The
suggestions herein recognise that there will be different levels of responsibility and
"ownership" of the issue, spanning business and technical domains. They also
allow that there will be significant variations in detailed role allocation, dependent
upon the size and complexity of a particular brigade and its IS/IT history.
The developing general UK pattern for Year 2000 compliance management now points clearly to the chief executive and board of management of both private and public organisations as having clear top-level responsibility. Pending legislation may make this legally enforceable/actionable for corporate bodies. In the Fire Service, this translates in each brigade as direct responsibility by the Chief Fire Officer.
Clearly, the principal officers cannot be expected to handle detailed compliance assessment/testing activity. The process must be managed as a project or a number of projects (referred to as a programme); for example as described in Home Office guidance for the acquisition of a mobilisation and control system; but the resources required will depend on each brigades assessment of its needs.
|Other Bodies||Brigades will also need to assess how far their responsibility should extend in alerting organisations which have fire risks which may be affected by computer malfunction.|
4. YEAR 2000 COMPLIANCE ACTION PLAN
|Overview||This section describes a framework for brigades to use to enable them to overcome Year
2000 problems in a well managed, structured environment. The Framework is based on the
operational and business use of systems, rather than starting from a technical-fix
Comprising five phases, the framework defines a structure to assess the situation, evaluate the options to overcome problems, undertake the detailed planning and manage the system change programme:
|Assessing the situation||Through the use of focused working groups involving a mix of technical and user representatives, a set of risk questionnaires is completed. The results will pinpoint the scale and intensity of the Year 2000 problem and provide a snapshot of how vulnerable the brigade is to experiencing date-related problems. The level of effort required and the cost of remedial action can be better assessed at this point.|
|Evaluating the options||A team approach considers the alternative courses of action available, this includes manual procedural change options as well as the technical fix alternatives. Evaluation will need to take full account of the skills required and overall costs (including indirect ones).|
|Seeking by-products or additional benefits||In considering alternative options, the brigade should specifically review whether
there may be opportunities to gain additional business benefits from the necessary change
actions. Since there may be significant disturbance and cost in Year 2000 compliance
actions, it may be worth "going the further mile" in order to add extra value -
perhaps by undertaking functional or technical upgrades as add-ons to the primary
In some instances, it will make more sense to accelerate replacement of legacy systems or sub-systems, rather than simply sink funding into making them compliant at the same level of capability and serviceability
|Planning to tackle the problem||For each option, the financial implications are analysed. This covers all costs of changes to systems, testing, additional computer facilities, implementation and integration with other systems and staff training issues. The selected options can then be planned in detail. This could be a complex exercise for some brigades with large numbers of systems.|
|Managing the change Programme||In larger brigades a number of projects may be managed together under a
Programme structure. The Programme should be designed to deliver positive progress at
regular milestones, in order to provide ongoing assurance to senior management that the
Year 2000 risk is being managed effectively. The management process also provides an
opportunity to test whether other benefits have been achieved, such as process
rationalisation or administrative task reduction.
Year 2000 compliance work will inevitably affect some pre-existing programmes or projects. This phase of work will need to resolve conflicts arising from these.
|Risk assessment||When assessing the risks of their Year 2000 programmes, brigades should bear in mind a number of risk factors which will have greater weight than usual in IT projects|
4.2 Assessing the situation
|Context and business environment||Each brigade has a responsibility to assess the extent to which its operations could
be adversely affected by incorrect date processing around the Year 2000.
Although the problem is technical, it can have fundamental effects on the way vital systems operate and interfere with working practices. Therefore the problem should be tackled from a business perspective. This will entail senior management involvement, setting a realistic budget, assignment of necessary personnel, ensuring sufficient computer resources are available, taking steps to ensure cross divisional working and implementation of project and change management procedures.
|Setting assessment objectives||The objectives for the assessment should be agreed by senior officers and then
communicated to all levels. The assessment will establish the impact the Year 2000 date
change could have on the operational capability of the brigade.
Objectives should include:
|Undertaking the Assessment||The actions needed to undertake an assessment will vary between brigades, and will be
affected by the size of the brigade, extent of computerisation, and numbers of IT staff.
To make the assessment brigades should:
|The Assessment Results||The assessment results will be in a document which contains information on:
4.3 Evaluating the options
|Context||To decide on the most practical approach to the problem, management will wish to consider alternatives, and take into account the impact on the brigade as a whole, rather than each individual operational system in isolation.|
|Options of the Evaluation||It is vital that senior management assess the practicality of each of the options being considered, taking a wide business view.|
|The evaluation will consider:
|Undertaking the Evaluation||To evaluate your system you will need to:
|Results from the Evaluation||The results should demonstrate that a realistic assessment of the available options
has been made. There should also be sufficient evidence to justify the recommended course
of action. This evaluation evidence may include:
4.4 By-products and additional benefits
|Seek business gain||Simply fixing date problems in existing systems will eliminate risks and secure
operations. However, it is an essentially sterile and unproductive investment, reactive in
In developing action plans and specific tasks for specific problems, it is strongly recommended that brigades try to identify ways in which additional benefits can be obtained. The point is that if systems have to be "opened up" in order to tackle date issues, it may well be possible to achieve some additional improvements in their performance, reliability and/or functionality. In some instances, it may be possible cost-effectively to add sufficient enhancements to prolong the life of legacy systems.
|Fix or replace?||In deciding what to do about non-compliant systems, it will usually be appropriate to
consider whether outright replacement is a viable and cost-effective option. Factors to
bear in mind here include not only the direct costs, but also the trade-off between the
extra functionality and fitness for purpose which a new procurement could deliver, set
against the likely greater project effort required to specify and implement a complete
Given the limited time available for date compliance, many otherwise viable replacement alternatives may be ruled out as too risky.
4.5 Planning to tackle the problem
|Importance of planning||The failure of many IT projects can be traced back to inadequate project management - which is itself heavily dependent on the planning process. The degree of success of individual brigades in achieving their Year 2000 objectives will rest on the creation of appropriately detailed and comprehensive plans. Brigades with extensive computer systems, or those with large numbers of bespoke options are likely to be most at risk and will therefore derive most benefit from investment in the planning process.|
|Objectives of planning||The planning phase will provide a structure for work within the brigade to achieve its Year 2000 compliance objectives. This will facilitate senior management monitoring of progress.|
|Key steps to develop a plan||Each brigade should develop plans which contain the following elements:
|Outputs from planning work||A Project Initiation Document (This term derives from the PRINCE project management
methodology) is needed at a realistic level of detail, including cost and time estimates,
a list of the major work which has to be undertaken, target dates and responsibilities.
This will incorporate:
|Contingency planning||In many cases, Year 2000 projects cannot afford to slide back on delivery dates; the margin available is simply to tight. The planning process must explain what will happen if delivery timings prove impossible to meet in any critical areas.|
|Contingency Actions||Actions to be taken might need to include such options as drafting in temporary extra
manual effort to keep business processes operating if systems fail. It may be possible to
hand over some or all processing to an external supplier for a period.
It must be recognised that some contingency actions could stand to incur significant costs if set in train.
4.6 Managing the Change Programme
|An iterative approach||The immovable end-date for Year 2000 work (where forward-date processing requirements
do not in fact impose a shorter deadline) means that there is little time available for
getting projects wrong and restarting.
In this context, it is all the more vital that the Year 2000 programme should incorporate a frequent re-examination of the inventory of systems to be assessed/dealt with. Experience to date has suggested that the numbers of systems, computer types and devices to be tested in organisations is far greater than at first meets the eye.
It seems quite probable that any brigade is likely to overlook some of the systems at risk. Checking and re-checking the inventories and the conclusions of the assessment exercise is one way of tackling this.
|Impact on other projects and programmes||Year 2000 compliance work will inevitably affect some pre-existing programmes or
projects. Managing the business and resource conflicts this may create could be an
important part of the work
It should be apparent that the severe potential business pressures that may be generated by such conflicts act as a further reason for brigades' ensuring that these key roles are filled by appropriately senior/experienced officers.
5. COMMENTARY ON SPECIFIC ISSUES
5.1 Relations with others
|Interfaces||When data is transferred between systems, or downloaded from a central system to a
local personal computer, it is vital that the approaches to handling Year 2000 dates are
compatible. Otherwise there may be real risk of a date fix in one system triggering
unforeseen problems in dependent areas of other systems to which it passes data.
Tackling this will require careful design and planning, especially when outside organisations such as Local Authorities are involved.
It must be recognised that when two or more systems are interfaced, it will not be enough simply to test the compliance of each separately. In many cases, the interface(s) will have been built as a separate exercise (by a supplier or internally). The software standards/ structures used may well differ from both (or all) the systems interfaced. If any date-related data is passed between the systems, the interface may have been constructed to include a translation function, changing between different date formats in the different systems.
The burden of this is that interfaces must be assessed for compliance in their own right. Testing routines must explicitly test the compliance of the interfaces in a comprehensive working scenario.
|Outsourcing / FM||Any brigade with systems provided or supported under an outsourcing or Facilities
Management arrangement will need to assess these just as rigorously as in-house
facilities. To the extent that legacy systems may have been handed over to an FM provider,
these are perhaps by definition more likely to be of an age to suffer Year 2000
Many brigades have legacy applications provided by related local authorities. These fall under the same rules as any other outsourced systems.
|Supplier Assurances||Probably a majority of fire service systems have been provided by external suppliers.
If the supplier is still providing a maintenance/support arrangement, it will be important
to examine very carefully whatever commitments or assurances are given about Year 2000
Statements that an application does not currently comply, but will do by a certain future date, should be assessed for various aspects of risk.
Ultimately, brigades need to take tangible actions to test the compliance of systems on which they are dependent. A supplier assurance might (if solid enough) form a basis for subsequent legal action, but this could be poor comfort if brigade operations and the public had been severely impacted by a major systems failure.
|Brigadess Major Risks||Brigades will need to assess whether they should seek assurances from major risks, such as those in the petrochemical industry, that adequate measures are being taken to prevent Year 2000 related failures.|
5.2 RISK MANAGEMENT
|Background||Much of these Notes discusses various aspects and types of risk in Year 2000 rectification work. It should be recognised, however, that in one sense the Year 2000 Programme is itself an exercise in risk assessment and management.|
|Risk Areas||Other areas of the Notes have pinpointed specific risks to be addressed. In formulating Programme structures, brigades should incorporate plans and structures for the main types of risk to be tackled. These will fall into several overlapping categories.|
|Business Risk||For example, conflicts with other key organisational priorities or projects sapping
effort from the Year 2000 Programme; or the strategic risk of organisational/structural
change in the brigade effecting the realisation of additional/side benefits identified as
supporting Year 2000 projects.
A major potential source of business risk lies simply in the potential failure of a brigade to address the Year 2000 problem with a coherent approach, managed by an appropriately senior individual (who will still be on the establishment in 2000!).
|Technical Risk||Examples might include the Year 2000 fix/replacement projects incorporating new and unfamiliar/untested technologies or reliance on being able to turn existing technology facilities to uses and deployments not previously experienced.|
|Supplier Risk||The scope, scale and track record of suppliers need to be considered. Does the supplier have a track record of delivering on promises on time? Are there known distractions impacting the suppliers team - other major projects for instance?|
APPENDICES1. Hardware/Platform Risk Assessment
The computing environment in most brigades will be a mixture which comprises proprietary and open systems, terminal and client server, centralised and decentralised systems.
When assessing risks consider, for each system:
For each of these areas you should discuss with your supplier:
2. Checklist for Action (Computer Systems)
The following provides a proforma for management responsible for the implementation of
Year 2000 computer system changes
|Area of Concern||Yes||No|
|A full assessment of all business processes has been conducted to identify dependent systems|
|All local and stand-alone systems have been identified and Year 2000 problems assessed|
|All local departmental systems have been identified and Year 2000 problems assessed|
|All ancillary systems (security, call logging etc.) systems have been identified and Year 2000 impacts assessed|
|A Year 2000 date standard has been defined|
|A Change Programme has been defined and responsibilities arranged|
|Earliest/latest compliance dates have been identified for each system|
|Liaison has been established with all manufacturers suppliers|
|Budget estimates have been prepared and are authorised|
|A plan containing key milestone dates and resource implications has been prepared|
|Programme risks have been assessed thoroughly and independently checked|
|A risk management plan has been prepared and responsibilities assigned|
|Contingency arrangements have been identified|
|A regular-interval programme progress reporting process has been established|
Checklist for Action (Embedded Systems)
Embedded systems - sometimes referred to as embedded processors - are computer-chip-based sub-systems built into many electronic devices. Concern has been growing that many of these have date functions built into them which may fail when dates change from 19xx to 20xx formats.
It is important to recognise that this risk may not depend upon whether the particular device has any explicit date-dependent functions to perform in the particular device concerned. As just one example, a major international burglar alarm supplier has estimated that approximately 20% of the alarm systems which it has supplied and which are still in use will suffer problems of greater or lesser severity at the date change.
The very breadth of the embedded-systems exposure makes it difficult to address. Brigades will need to undertake a general risk assessment to identify the areas where greatest risk to operations and public or officers safety may arise.
Where possible, this will mean obtaining unequivocal statements of the position from the suppliers of devices concerned. Where this proves impossible for any reason, the key alternatives are likely to be to bring forward planned replacements/upgrades, or to put in place manual contingency work-arounds to cope in the event that devices fail around the date change.
The following checklist of device types which might be affected is not, and cannot be,
|electronic locks||burglar and fire alarms||heating and ventilation systems|
|lifts/elevators||CCTV cameras/monitors||sprinkler systems|
|vehicle management systems||photo surveillance equipment||time clocks/stamps|
|radios||traffic light controllers||faxes|
|radio sub-stations||mobile phones||telex machines|
|telephones & switches||pagers||car park barriers|
|remotely operated doors||personal organisers||schedule systems for maintenance (e.g. fire extinguishers)|
4. British Standards Institution (BSI) Definition
The BSI document PD 2000-1: 1998 which is quoted below contains the formal definition
of the expression "Year 2000 conformity" developed by the British Standards
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 1||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 inferencing rules.|
|Rule 4||Year 2000 must be recognised as a leap year.|
AMPLIFICATION OF THE DEFINITION AND RULES
|General Explanation||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
To avoid such problems, organisations 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. Where checks are made with external suppliers, care should be taken to distinguish between claims of conformity and the ability to demonstrate conformity.
|Rule 1||1.1 This rule is sometimes known as general integrity.
1.2 If this requirement is satisfied, roll-over between all significant time demarcations (e.g. days, months, years, centuries) will be performed correctly.
1.3 Current date means today's date as known to the equipment or product
|Rule 2||2.1 This rule is sometimes known as date integrity.
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.
2.3 The meaning of functionality includes both processes and the results of those processes.
2.4 If desired, a reference point for date values and calculations may be added by organisations; e.g. as defined by the Gregorian calendar.
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".
|Rule 3||3.1 This rule is sometimes known as explicit/implicit century.
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 standard 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 inferencing 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 inferencing as a whole must apply to all contexts in which the date is used, although different inferencing rules may apply to different date sets.
|General Notes||For Rules 1 and 2 in particular, organisations may wish to specify allowable ranges
for values of current date and dates to be manipulated. The ranges may relate to one or
more of the feasible life-span of equipment or products or the span of dates required to
be represented by the organisation's business processes. Tests for specifically critical
dates may also be added (e.g. for leap years, end of year, etc.).
Organisations may wish to append additional material in support of local requirements. 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".
Fire Research & Development publications
Fire Research and Development Group (FRDG)
Fire and Emergency Planning Directorate (FEPD)
Home Office front page
© Crown Copyright 2000
Page last updated 18th January 2000