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