Strange may it sound, but the LIS folk are yet to wake up to the fact that the Year "2000" is just about 15 months away. Library routines entail dealing with "dates" — all kinds of date fields for making overdue statements, cataloguing books, sending reminders to suppliers, weeding out old documents, sending claims, preparing bibliographies and a host of such activities. These often demand comparisons with a given date. So long as the activities are manually carried out, one has a chance to apply reasoning and avoid confusion. However, today many library and information centres use computers which can make only blunt comparisons. The IT savvy library and information professionals ought to sit up now and ponder a while whether they could go terribly wrong at the turn of the century.
The year 2000 or Y2K problem, or the millennium bug is a product of omission — the practice of representing the year in two digits knocking off the leading "19". When a year is referred as "98", we mentally add "19" and recognize the year as "1998". On 31st Dec 1999 midnight, such 2-digit representation of the year would be "00". A computer will be confused — should it take it as 2000, 1900, 1800 or...? If a librarian then wants to compile all additions to the holding in the last two years, should it retrieve the records for the years 1998 to 2000 or 1898 to 1900 or...In other words, all arithmetic operations on sorting by dates would go haywire. The problem appears simple to solve and in fact it is simple. However, when such data comparisions become all pervasive, as in financial systems, life could indeed be quite difficult.
There is a problem in the leap year calculation also. We all know that if the year is divisible by "4", it is a leap year. The calculation works uniformly fine except in the case of century years. The century years 1900, 2100, etc. though divisible by "4" are not leap years. Only when the century year is also divisible by 400 as in the case of 1600, 2000, 2400 and so on, one extra day is to be added in February. That means, a computer system should be able to recognize Feb 29, 2000 as a valid date.
How come that this Y2K problem has surfaced only now? Were the systems designers of yester-years all fools or what? Not at all, they were just constrained by the need to save memory space at that time. These space saving methods in old mainframe and similar systems, percolated down to today's PC world. The problem thus proliferated, programmed to strike all walks of life wherever computers are used — library and information centres will not be spared.
In the first instance, one should assess where all the data processing logic is dependent upon dates. For example, access control — activation or deactivation of passwords, expiry of membership due to superannuation of members, termination of subscription period, over-due accounts, renewal of serial subscriptions, etc. depend upon dates. In fact it would be proper to take a complete inventory of all application programmes, supported and unsupported, packaged software, applications developed by end-users and ascertain where dates form a key field. A close look at the existing practice of rendering dates by various functioneries, and the computer systems they use, will be worthwhile.
Thereafter, two checks are to be performed. One, how the dates are represented in each field at the input stage. If the year is entered in two digits, one should rush to call Sherlok Holmes to find out how these are being used in the processing stage by painstakingly going through the entire logic of the programmes. Even if the input data on year is in four digits, one need not be elated. Program logic often asks for dates from the system to perform the scheduled comparisons. The second check therefore, is to ascertain as to how the data on year is provided by the system — in two or four digits?
If the checks reveal that such problems indeed exist, it is better to entrust the job of conversion to a professional software group instead of tinkering with the problem oneself. However while making new acquisitions, one should ensure that the hardware - software system is roll-over compliant.
The problem does end by ensuring that one's own system would work smoothly from Jan 1, 2000. If the system exchanges information with others, which is common in a network environment, it is essential that those systems are also Y2K compliant. For example, if the library system is linked to the Finance & Accounts system, both of these ought to be roll-over compliant.
In effect, it is an enterprise-wide issue which needs to be tackled on a holistic basis and as a priority. Let not system disruptions stir us out of bed (or new year party) at the stroke of the midnight of Dec 31, 1999!
