Apache JServ Year 2000 Compliance and Safety

Every organization serious about avoiding Year 2000 (Y2K) crashes and errors is checking each piece of software in use as we near the turn of the century. The Apache JServ servlet engine is Y2K complaint/safe. 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

The Y2K compliance status of a system that includes the Apache JServ servlet engine will also depend on the following factors:

Web Server
The Apache JServ servlet engine receives requests from an Apache web (HTTP) server, 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.
Java Virtual Machine
Most of the Apache JServ code 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 Win32 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. 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.
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.

Categories of Clock Rollover Bugs

When making sure your servlets and system software will behave correctly, there are several clock rollover bugs that need to be considered, not just January 1, 2000.

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.
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.
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.

Y2K and Clock-Rollover Bug Links

Year2000.com index