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
- 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.
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,
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
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
- 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
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
Copyright (c) 1997-98 The Java Apache Project.
$Id: y2k.html,v 1.6 1999/06/09 05:21:23 jonbolt Exp $
All rights reserved.