RFC 2550:Y10K and Beyond
RFC-Ref

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.

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

1.2.1. Introduction

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

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

The granularity problems of a fixed format date can be improved by extending the date format to include greater precision in the date. However, since numerical comparison of dates requires a fixed representation date, an extended format can not provide sufficient resolution for all foreseeable needs.

For instance, if the precision were extended to the femto-second range the date format would become YYYYYMMDDHHMMSSmmmuuunnnpppfff (year, month, day, hour, minute, second, milli-second, micro-second, nano-second, pico-second, and femto-second). The additional 21 digits of this format limit the set of representable dates. Compared to 1.2.2, the 32-bit and 64-bit forms of the date are instantly exceeded, while the 128-bit version would be viable - expiring on December 31, 17,014,118,346,046.

1.2.3.1. Extrapolation of Future Granularity Issues

However, a simple extrapolation of Moore's law shows that even femto-second resolution will soon be inadequate. Projecting current CPU clock speeds forward, a femto-second clock speed will be achieved in only 30 years. And, by the year 10,000 the projected clock speed of the Intel Pentium MMDCLXVI (TM) will be approximately 10 ** (- 1609) seconds.

This discussion clearly shows that any fixed-format, integer representation of a date is likely to be insufficiently precise for future uses.

1.2.3.2. Floating Point Is No Solution

The temptation to use floating point numbers to represent dates should be avoided. Like the longer fixed-format, integer representations of the date, floating point representations merely delay the inevitable time when their range is exceeded. In addition, the well known problems of real numbers - rounding, de-normalization, non-uniform distribution, etc. - just add to the problems of dealing with dates.


Google
Web
RFC-Ref