Elsop's Year 2000 Compliance Statement
Date and time information accepted, stored, manipulated and displayed by LinkScan (Version 4.0 and higher) is accurately processed for all dates in the range January 1, 1970 to December 31, 2036, provided that the underlying Hardware, Firmware and Operating System correctly process dates in that range and that LinkScan is used in accordance with the current user documentation. This statement is not a product warranty. Warranties for Elsop's products are set forth in the end user license agreements that accompany the products.
How Does Unix Handle Dates
All date/time data are represented using the standard Unix convention; a 32-bit signed integer containing the number of non-leap seconds since January 1, 1970, UTC. This allows accurate processing of dates in the range 1970-2038.
It is widely recognized that most 32-bit Unix systems currently include limitations that prevent the accurate representation of dates beyond the year 2038.
Most 64-bit Unix systems will not have a date problem for several hundred million years. We believe that 64 bit or larger Unix systems will be the standard long before 2038.
It is Elsop's intention to enhance LinkScan to handle dates beyond that range on 32-bit systems in accordance with whatever de facto and/or de jure standards emerge over time. All of our products work on 64-bit Unix systems, so when they become a standard the problem will go away. We also expect that the Windows NT operating system will migrate to a 64-bit architecture within the next decade.
How Does LinkScan Handle Dates
All date/time manipulations are performed using standard operating system procedure calls. LinkScan has been tested in several environments to confirm correct operation in year 2000. In fact, it has been tested to the year 2037 without a problem and is, therefore, Year 2000 or Y2K Compliant.
The de facto standard for date/time representation on all Unix systems is an integer containing the number of non-leap seconds since January 1, 1970, UTC. All that LinkScan does is:
a) Retrieve the integer time using the standard Perl library routine time() and store it in various data files.
b) Convert the integer time to a human readable ASCII string using the standard Perl library routine localtime(). The exact format depends on the Operating System and Time Zone but this is typical:
Tue Mar 17 12:44:12 1998
c) Compare date/time information by subtracting two such integers.
Most Unix systems (and therefore integers) are 32-bit today. Hence those integers will overflow when the number reaches 2^^31 (two to the power of thirty one) seconds. That will happen in 2038. Of course, the chances are that most machines will be operating in 64-bit (or longer) mode by that time.
As far as we know, there is no current consensus on how to handle this in the Unix community. Most people are much more concerned about the "two-digit year" problem. i.e. 99 rolling over to 00 which is not an issue for Unix Systems if standard system routines are used, as is the case with our products.