Kendra Electronic Wonderworks warrants UUPC/extended for year 2000 compliance as much as we do the rest of the program which is to say, not at all. For details on our lack of warranty, see the UUPC/extended license,
Users requiring UUPC/extended to be certified as year 2000 compliant are invited to:
The following discussion of UUPC/extended behavior applies to release 1.13b and above only. No claim is made as the expected behavior of the UUPC/extended releases prior to 1.13b.
While we cannot warrant the program for year 2000 compliance, we do not expect any issues with the UUPC/extended code because of year 2000 compliance issues as outlined above.
UUPC/extended internally uses the UNIX style C run-time library support, which keeps time as a linear sequence of seconds since 00:00:00 GMT on January 1, 1970. To this method of time keeping, rollover from 1999 to 2000 is just another tick of the linear clock, and no special processing is required.
UUPC/extended uses the time and/or date in the following areas:
To the best of our knowledge, all of these operations are done in a year 2000 compliant fashion.
For UUPC/extended to operate properly, both the Personal Computer (PC) BIOS (hardware clock) and operating system must be year 2000 compliant and the clock must be properly set. A full discussion of these issues is beyond the scope of this document.
Note: A suggested resource on general PC year 2000 compliance is available at the MITRE/ESC Year 2000 Web Site.
UUPOLL is documented to poll at non-standard intervals on those days where a system is transitioning to or from daylight savings time. Refer to the UUPOLL command reference in UUPC/extended manual for the exact description of how UUPOLL handles daylight savings.
Since the standard UNIX time value is stored in a 32 bit signed value on many systems (including all Intel x86 systems supported by UUPC/extended), the UNIX epoch is only valid for just over 2.1 billion seconds, or until early January 2038. At that time, UUPC/extended will cease correct operation.
Note: Virtually all current 32 bit UNIX operating systems and applications using the UNIX Epoch for time keeping will have similar problems.
Because fixing the UNIX Epoch problem requires as yet unreleased vendor libraries and compilers from the various system vendors, we have no current plans to correct this problem.