Y10K and Beyond
RFC 2550

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                       S. Glassman
Request for Comments: 2550                                   M. Manasse
Category: Stinkards Track                                      J. Mogul
                                            Compaq Computer Corporation
                                                           1 April 1999

                            Y10K and Beyond

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   As we approach the end of the millennium, much attention has been
   paid to the so-called "Y2K" problem.  Nearly everyone now regrets the
   short-sightedness of the programmers of yore who wrote programs
   designed to fail in the year 2000.  Unfortunately, the current fixes
   for Y2K lead inevitably to a crisis in the year 10,000 when the
   programs are again designed to fail.

   This specification provides a solution to the "Y10K" problem which
   has also been called the "YAK" problem (hex) and the "YXK" problem
   (Roman numerals).

1. Introduction, Discussion, and Related Work

   Many programs and standards contain, manipulate and maintain dates.
   Comparing and sorting dates is a common activity.  Many different
   formats and standards for dates have been developed and all have been
   found wanting.

   Early date formats reserved only two digits to represent the year
   portion of a date.  Programs that use this format make mistakes when
   dealing with dates after the year 2000.  This is the so-called Y2K
   problem.

Glassman, et. al.            Informational                      [Page 1]
RFC 2550                    Y10K and Beyond                 1 April 1999

   The most common fix for the Y2K problem has been to switch to 4-digit
   years.  This fix covers roughly the next 8,000 years (until the year
   9999) by which time, everyone seems convinced that all current
   programs will have been retired.  This is exactly the faulty logic
   and lazy programming practice that led to the current Y2K problem!
   Programmers and designers always assume that their code will
   eventually disappear, but history suggests that code and programs are
   often used well past their intended circumstances.

   The 4-digit year leads directly to programs that will fail in the
   year 10,000.  This proposal addresses the Y10K problem in a general
   way that covers the full range of date and time format issues.

1.1 Current approaches

   A large number of approaches exist for formatting dates and times.
   All of them have limitations.  The 2-digit year runs into trouble
   next year.  The 4-digit year hits the wall in the year 10,000.  A
   16-bit year runs out in the year 65,536.  A 32-bit counter for the
   number of seconds since 1970 [UNIX] wraps in 2038.  A 32-bit counter
   for the number of milli-seconds since booting crashes a Windows (TM)
   PC in 49.7 days [Microsoft].

   In this specification, we focus on the Y10K problems since they are
   most common and a large number of existing standards and protocols
   are susceptible to them (section 7).  These standards, and new
   proposals on their way, will lead to a serious world-wide problem
   unless efforts are made now to correct the computing, government, and
   business communities.

   Already, a small cottage industry is popping up to deal with the Y10K
   problem [YUCK].  We encourage these efforts and, in the coming years,
   this effort can only grow in size and importance.

1.2 A Fixed Format Y10K Fix

   At the time of this writing, only one proposal [Wilborne] directly
   deals with the Y10K problem.  In that proposal, dates are represented
   as decimal numbers with the dates compared numerically.  The proposed
   format is simply YYYYYMMDD - i.e. 5-digit years.

   To allow numerical comparison of dates, this representation requires
   a completely fixed representation for the date.  There can be no
   optional fields, the date resolution is limited to the granularity of
   one day, and this solution fails in the year 100,000 (Y100K).

Glassman, et. al.            Informational                      [Page 2]
RFC 2550                    Y10K and Beyond                 1 April 1999

1.2.2 Limitations of Numerical Comparison

   While sufficient for the specific Y10K problem, this solution is
   limited.  Even if extended for 6-digit years, it fails on 32-bit
   systems (and future 32-bit system emulators) after the date
   represented by the number 2147481231 (December 31, 214748) leading to
   a Y214749 problem.  Similarly, 64-bit and 128-bit systems also will
   fail, although somewhat later (after December 31, 922,337,203,685,477
   and December 31, 17,014,118,346,046,923,173,168,730,371,588,410
   respectively).

1.2.3 Granularity Issues