To encourage businesses to address the problems posed by computers finding they are at year zero, the previous government established Taskforce 2000 to raise awareness of the issues to the business community. Robert Guenier, the head of Taskforce 2000 has consistently told the media that preparation in Britain is "woefully inadequate" and that too many firms are leaving it too late to make corrections to their systems. This complacency was underlined by a report published in March by PA Consulting who found that although 93% of the senior UK managers had heard of the problem, only 28% were fully aware of its implications and as few as 9% of the businesses surveyed had taken steps to address it.
The problems posed by the year 2000 arise from the computer industry-wide convention of storing years as two-digit numbers. You only need to look at the expiry date on your credit card to see an example of this (do you have a card that expires in "00" or "01" yet?). The difficulty arises when the date is compared with another date, for unless the computer program has been modified to deal with this event, it is likely to assume that "00" is 1900. As you can imagine, calculating the number of days worked in a payroll package, or the amount of interest to pay in a financial system is likely to be unpredictable in a most spectacular way.
Market research is in many ways a special case. On the one hand, as businesses, we use the usual standard packages for handling word processing, accounts, and maybe payroll too. On the other, we tend to use a lot of software developed exclusively for the market research community, and often augment this with systems we have developed ourselves. Furthermore, we collect and process vast amounts of data, and frequently decide the format of that data, including how to represent dates or years on an ad hoc basis.
Whatever happens, your computer or operating system is likely to function perfectly. UNIX, Windows 95 and Apple Macintosh systems are all fine. You may have problems with older windows or DOS systems, though: not all of these are millennium compliant.
If you use software supplied by one of the specialist producers, then you should have nothing to worry about. I spoke to Mercator, who produce Snap, Pulse Train, producers of Bellview and Quantime, who produce Quantum, Quancept and Quanvert, and all said that they had taken steps to ensure their customers would not experience any malfunction due to dates on or after the year 2000. Furthermore, to get this problem into perspective, the problem only affects dates that are being compared with other dates, which is a very small
Iain MacKay, technical director at Pulse Train told me that a new release in November would ensure their customers' systems would be fully millennium ready. Peter Wills, director at Mercator said about dates after 2000, "we've done it in a very straightforward way. No-one using SNAP should experience any problems." Similarly at Quantime, they predicted no problems since they rely on the date value built into the UNIX operating system which uses a completely different method for recording the date and is definitely ready for the year 2000. All three manufacturers I spoke to revealed that some of their customers had been in touch to seek guarantees on millennium compliance. More remarkable is that the majority have not been seeking any such guarantees.
Pat Molloy, who is Technology Development Director at NOP, told me that they had set up a small internal group to review all of the software they use. They were satisfied with all the externally sourced software they used, but were concerned about some of the smaller utilities and routines they had developed themselves. "We have done an internal trawl of all systems for accounts, also sampling, field and personnel systems. What you read in the press is probably going to affect more the big financial institutions. As far as we can tell, the only things that need changing are some of our sampling programs". These are the ones which reply most heavily on date comparisons: when someone reaches a certain age, last time they were contacted, next time they could be contacted and so on. "We've tested most things by switching the system date forward to the year 2000. It is possible that something might creep out of the woodwork but they are not likely to be show stopper things." Pat pointed out that, when analysing data, especially back data or trend data, extra vigilance would be required in future.
Raz Khan at ATP, as independent specialists in data processing, is very aware of the responsibility they face in ensuring their clients have no nasty surprises in the tables or reports they receive after 1999. They have been asked to conduct what they call a "sanity check" for some of their clients. "There are standard things to look for in any job, such as a date of birth. People are very reluctant to increase the size of the fields on dates to allow four digits for years." When this happens, they build in a routine to establish a sensible "watershed" date. This is similar to the method built into SNAP where years "28" and "29" are assumed to be 2028 and 2029, "30", "31" onwards are assumed to be 1930, 1931 etc.
However, as Iain MacKay points out, 2000 is probably not the only date that may give rise to problems. "You should be aware of any 'magic values' which are not real years". This is a good point, given the tendency of researchers to use values such as 99 to mean "Don't know" or "Refused". Plus, by setting a watershed date such as 2029, we are in effect setting a future timebomb. Even the systems that are guaranteed to work properly across the millennium divide do eventually come to grief. As Pat Molloy points out, UNIX dates stop working after 2078. I found the same applies to dates in Microsoft Excel. So it looks as if subsequent generations could find themselves vexed with the "twenty nine deadline" or the "seventy eight scenario". Just remember you heard it here first.
Five steps to millennium good health
© Copyright Market Research Society/Tim Macer 1997. All rights reserved. Reproduced with permission.