WIN-PROLOG: Year 2000

This document discusses WIN-PROLOG with respect to Year 2000 ("Y2K" or "Millennium Bug") compliance. Many personnel in the IT business were extremely concerned about what was going to happen to their computer systems between 31 Dec 1999 and 01 Jan 2000. Fortunately, in the event, the widely predicted meltdown failed to occur; but even today, many legacy systems still contain code which misbehaves in respect of Y2K. While addressing these concerns, the present document also draws attention to several related issues in date/time handling, and explains how these are overcome in WIN-PROLOG. Six primary topics are considered:

• Year 2000 or "Y2K" Truncation: why the classic Millennium bug does not affect WIN-PROLOG itself, but may appear in some of the documentation examples
• Year 2000 Rollover: how WIN-PROLOG and its programs will behave before, during and after the Y2K rollover
• Leap Year 2000: why the year 2000 is a leap year, and how this affects WIN-PROLOG and its programs
• The Midnight Rollover Bug: how to avoid a common programming error which can affect any software system once per day
• The 32-bit Ticker Overflow Bug: what happens to Windows after it has been running for more than 49 days
• CMOS, BIOS and Operating System Bugs: how to ensure that the underlying hardware and software works correctly

Year 2000 or "Y2K" Truncation

This bug is the main current concern of systems administrators, and is usually referred to as the "Millennium Bug" or simply the "Y2K Bug". Its origin stems from the tendency of computer programmers to save space wherever possible: two bytes could be released for other storage purposes by omitting the "constant" characters "19" from year fields, with the result that two-digit representations of years within date strings are commonplace.

The only serious problem relating to this bug is that when two dates in "DD/MM/YY" or other 2.2.2 format are compared, the year 2000 will be treated as "00", rather than "100". Without appropriate corrections, such programs will therefore consider the date 01/01/2000 to be a day less than one hundred years earlier than 31/12/1999, rather than one day later.

The WIN-PROLOG system never uses formatted dates in computations, and so is completely immune from this bug; however, a few of the documentation example programs use dates as labels and titles, and some of these may only use a 2-digit year fields: this is not considered a serious issue, and does not prevent the examples from otherwise working correctly.

All dates returned by WIN-PROLOG's system predicates use full 4-digit year designations, and will correctly return the date both before and after the year 2000, unless the underlying computer BIOS or Operating System fails (see below).

Year 2000 Rollover

As well as consdering the computational uses of dates (see above), it is important to discuss what happens to computer programs which are actually running during the night of 31/12/1999. Some systems, which use proprietary methods for incrementing dates, might rewind to an earlier date, such as 1/1/1980 (the earliest date supported by MS-DOS).

Subject to the correct behaviour of the underlying computer BIOS or Operating System (see below), dates returned by WIN-PROLOG's system predicates will move smoothly and correctly from (31,12,1999) to (1,1,2000) as the new millennium begins.

Leap Year 2000

There is considerable confusion about whether or not the year 2000 is a leap year. The simple and correct answer is that it is! The rule for leap years, as laid down in the Gregorian Calendar, is that:

	A year is a leap year if and only if:

		it is exactly divisible by 4 but not by 100
	or	it is exactly divisible by 400

By this rule, it can be seen that 2000 is a leap year. WIN-PROLOG's system predicates include facilities to convert between dates and day numbers, and these correctly implement the rules. Adding one day to 28/2/2000 returns the 29/2/2000, as does subtracting one day from 1/3/2000. In fact, the day/date conversion algorithm has been exhaustively tested against a second, independently implemented algorithm, for all dates between 1/1/1600 and 31/12/9999, and has been found to work correctly for every date in this range of over 8 millenia!

The Midnight Rollover Bug

Technically this is not a Y2K issue, although ironically it could cause problems on the night of 31/12/1999; however, this bug can strike code once per day. The "Midnight Rollover" bug occurs in any system which obtains date and time independently, without checking that the date has remained unchanged around the reading of the time. If the date and time are read just before midnight, there is a small but finite risk that the time will have rolled over from 23:59:59 to 00:00:00 the next day between the two readings. Consider typing the following Prolog query moments before midnight on a date, say, of 24/10/1998:

	?- date( Dy, Mt, Yr ),
           time( Hr, Mn, Sc, Fr ),
           X = [Dy,Mt,Yr,Hr,Mn,Sc,Fr].

Depending upon the exact moment <enter> was hit, these calls could return any of the following results:

	X = [24,10,1998,23,59,59,999]
	X = [24,10,1998,0,0,0,0]
	X = [25,10,1998,0,0,0,0]

The first and last readings are simply 1ms apart from each other, but the middle reading is wrong by a whole 24 hours. In a system designed to run only during office hours, and where the system clock is set to local time, the above bug can perhaps be ignored; however, in any system attached to a network, or to which any form of remote access might be required, this should be considered a serious bug.

The WIN-PROLOG 4.0 system completely eliminates this bug, because date and time are returned simultaneously by a new system predicate (time/2), and the midnight-rollover check is built in.

The 32-bit Ticker Overflow Bug

Again, this is not strictly a Y2K issue, but whilst on the subject of time and date handling, it should be noted that all current versions of the Windows operating system (including WinXP, Win2k, WinNT, WinME, Win98, Win95 and Win3.1) maintain a 32-bit millisecond counter which is used to return various system time values. 2^32 milliseconds is just over 49 days, and so this counter overflows and resets to zero every seven weeks or so.

While this is unlikely to cause serious problems, any server software which runs in the long term and relies on elapsed times, for example to name temporary files or generate serial numbers, should be aware that the Windows millisecond count is unsafe.

The WIN-PROLOG 4.0 system completely overcomes Windows' limitation by including its own, independent 64-bit counter which will accumulate elapsed millisecond counts for thousands of years without problems.

CMOS, BIOS and Operating System Bugs

Although WIN-PROLOG 4.0 is itself Y2K compliant, this system, and any software written with it, is only as good as the hardware and software platform upon which it subsequently runs. Many personal computers (PCs), especially those which are more than about a year old, are likely to fail to recognise the correct date on 1/1/2000. The severity of this problem is dependent collectively any one machine's CMOS real time clock, the programming of its ROM BIOS firmware, and on the operating systems it is running.

Some BIOS implementations will work correctly only when the machine concerned is left switch on overnight on 31/12/1999, others will work only when the machine is switched off overnight. Yet others will work correctly either way while a remaining set will fail in both cases. Additionally, if a date is manually set for some time in the year 2000, some BIOS implementations which failed to perform the 1999/2000 rollover correctly will subsequently work perfectly; others will always forget the year after powering down, requiring manual resetting each time the computer is switched on or rebooted. A machine's CMOS and BIOS can be checked by manually resetting the date and time and performing various tests, for example:

	1) Set the date and time to 31/12/1999 and 23:59:00
	   respectively, turn machine off, wait for just over a
	   minute, turn machine back on, and see if the date
	   and time correctly show as 1/1/2000 and 00:00:00
	   respectively.

	2) Set the date and time as 31/12/1999 and 23:59:00
	   respectively, leave machine on, wait for just over a
	   minute, and see if the date and time correctly show
	   as 1/1/2000 and 00:00:00 respectively.

	3) After (2) above, turn machine off, count slowly to
	   10, then turn machine back on, and see if the date
	   and time are still correct.

	4) Set the date and time to 1/1/2000 and 00:00:00
	   respectively, turn machine off, count slowly to 10,
	   turn machine back on, and see if the date and time
	   are still correct.

	5) Remember to reset the date and time to the present
	   upon completion of these tests!

Note that some operating systems (such as WinNT 4.0) will not allow date/time setting without special user privileges, while others maintain separate "local" and "system" times which make testing more complex. Note also that DOS itself has a long-term bug which sometimes causes the date to fail to advance at midnight, effectively rewinding the clock 24 hours: this can occur on any night, including 31/12/1999.

If a machine fails any of the above tests, it is possible that a BIOS upgrade is available from the manufacturer. If the machine upon which a WIN-PROLOG system is running system fails to return the correct date on or after 1/1/2000, then the WIN-PROLOG system will itself fail to work correctly. Any such failures of compliance are not the responsibility of LPA: please ensure that all host machines are year-2000 compliant!

Summary and Year 2000 Statement

This document has discussed Year 2000 or Y2K issues, together with some related date and time considerations. The WIN-PROLOG 4.0 system itself has been thoroughly checked and shown to be year-2000 compliant. The non-Y2K date and time issues (midnight rollover and ticker rollover) are safely and correctly handled in WIN-PROLOG 4.0. So far as Y2K itself is concerned, here is the statement everyone wants to read...:

Find out about WIN-PROLOG