Browse Prior Art Database

Y10K and Beyond (RFC2550) Disclosure Number: IPCOM000003136D
Original Publication Date: 1999-Apr-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 14 page(s) / 19K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Glassman: AUTHOR [+2]

Related Documents

10.17487/RFC2550: DOI


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

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 13% of the total text.

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.


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