Java-Apache Project
Y2K Compliance and Safety

However, there are dependencies on other associated software. And various software out there have more kinds of "date rollover" bugs than just January 1, 2000. This document will provide an overview.

Note that these clock rollover bugs also occur before the actual time arrives, when any forward-referencing time is used, such as an expiration date.

Y2K Dependencies on Other Software

HTTP Server Software

The Apache JServ servlet engine receives requests from a web (HTTP) server. Most of those servers are Apache HTTPD, which has its Y2K compliance statement as part of the Apache FAQ. In short, the Apache HTTPD distribution is Y2K safe with dependencies on the operating system.

Development versions of the Apache JServ now also serve NSAPI-compatible (Netscape servers) and ISAPI-compatible (Microsoft, O'Reilly and other servers) web servers. If you're using one of those, you will need to check with your web server's developer for further details.

Java Virtual Machine

The Apache JServ is written in Java. Therefore, the Java Virtual Machine (JVM) which executes the Java bytecodes provides the system environment, including timekeeping. The reference implementation of the Java standard is from JavaSoft. Their JVM implements timekeeping in a way specific to each operating system that the JVM runs on. Therefore, the JavaSoft JVM, and any implemented similarly, are Y2K safe with dependencies on the operating system, just like the Apache HTTPD is.

Operating System

Unix and Windows operating systems keep their time by integer quantities of seconds since an initial "epoch". These are Y2K safe but will have other clock rollover problems years further in the future. For other operating systems, you will need to check with the developer.

Servlets

Java Servlets are all late 90's technology so there should not be widespread ignorance of Y2K issues as there is with software written decades ago. However, each servlet has its own author and mistakes are possible. So for mission-critical operations, you should contact the servlet's author or refer to the source code if you have it. If your organization is so short on resources that some Y2K tasks can't be done, it's probably safe to give a low priority to investigation of new software like servlets since they're not likely sources of Y2K bugs.

GPS "End of Week" Bug
August 22, 1999

Any servlet or computer which uses timekeeping or position information from a Global Positioning System (GPS) receiver needs to check if the receiver is vulnerable to the GPS "End of Week" (EOW) bug. Among the data structures used to keep time, a 10-bit quantity was used for the number of weeks since January 1980. This allows for 1024 weeks and will roll over on August 22, 1999 (and every 1024 weeks, or 19-3/4 years thereafter.) Check with your GPS receiver manufacturer - some newer ones keep track of their date of manufacture and use that to avoid rolling over to a date before they were made. Others will roll back to 1980, resulting in incorrect time, position and navigation information.

Fiscal Year 2000 Rollover
various dates between April 1, 1999 and January 1, 2000

Organizations with fiscal years offset from the calendar year will hit the Year 2000 "Millenium Bug" when their FY2000 begins. For example, the Federal Government rolls over to FY2000 in October 1999. For businesses, governments and any entity that uses accounting software, the Fiscal Year 2000 may appear as FY1900 if the year is stored as a two-digit quantity and the century is assumed to be 1900. These bugs will occur when each organization reaches its Fiscal Year 2000, which means many of them will be occurring at different places most commonly on calendar quarter boundaries starting April 1, 1999, and it won't be an April Fools joke!

The "Millennium Bug"
January 1, 2000

This is the well-known bug where any date where the year is kept as as two-decimal-digit quantity will roll over to 1900. This is dealt with in detail by many Y2K sites around the web.

In any new software you write, care must be taken to avoid introducing new Y2K bugs while so many people around the world are trying to fix them! Do not use 2-digit years in any data, or in any output that could conceivably be used as input by another program, local or remote. Just to be safe, you should even use 4-digit years when printing them for user display.

The 2000 Leap Year Bug
February 29, 2000

Many programs compute their own dates from internal data structures. Cases have been found where they fail to identify 2000 as a leap year, because years divisible by 100 are not leap years unless they're also divisible by 400. 1800 and 1900 were not leap years but 2000 will be. Most Unix systems will handle this correctly and it's easy to test by setting a test system's date to the Leap Day, February 29, 2000. Systems which fail to recognize this will be a day off on all days past the Leap Day in 2000.

Operating Systems that coordinate their timekeeping libraries with the US Naval Observatory will be the most accurate, even including leap seconds each year after they're announced. Such operating systems that include updated timekeeping libraries with each new release are Linux and FreeBSD.

Win32 Application Rollover

The Y2K FAQ indicates that Windows 95 and NT operating system clocks can handle up to 2099 but some applications may use dates after 2000 or 2020 to turn the system clock back to 1900 or 1920, respectively.

Unix 2038 Bug
January 19, 2038

Unix clocks use a signed 32-bit integer quantity to represent the number of seconds since January 1, 1970 at midnight GMT. The 2.1 billion seconds covered by this algorithm will run out in the year 2038. Some time before then, Unix systems and applications will need to migrate to a 48-bit or 64-bit clock. This should not be a concern right now when actual Year 2000 issues in many organizations do not have enough resources to all be solved in time.

The original Unix developers at Bell Labs in the late 1960's and early 1970's used this number because they had no way to know how popular Unix would become. So they just chose a time scale that would outlast their own lifetimes.

• Year2000.com index