Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Despite all of the hooplah about Y2K, computer programmers and protocol
designers have not really learned from Y2K. Just because a problem seems
far off, it should NOT be ignored. 30 years ago, the year 2000 seemed
unimaginably far off and many protocols and programs were not designed
to deal with it. Now, we see a similar problem on the horizon and we
fear that most computer professionals are again looking the other way.
Starting with the year 10,000, years will have 5 digits. At least 16
RFCs and one ISO standard specify 4-digit years and countless programs
(including those fixed for Y2K) rely on 4-digit years. Given civilization's
projected dependence on computers in 8,000 years, the potential for disaster
is nearly unlimited. Given the possibility that code and protocols developed
today will still be running, we must begin dealing with the Y10K problem
immediately.
We have developed a proposal to solve the Y10K problem and released it
to focus attention on this looming catastrophe. It is available today
and can be found in any RFC repository. Its number is RFC2550 and is
titled "Y10K and Beyond". We strongly encourage all subscribers to the
Risks Digest to read it and heed its message.
Steve Glassman
[Among other places, this is in the official RFC repository at
ftp://ftp.isi.edu/in-notes/rfc2550.txt . PGN]
- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - =
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 document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. 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.
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).
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.
2 Structure of Y10K Solution
Any Y10K solution should have the following characteristics.
2.1 Compatibility
The format must be compatible with existing 4-digit date formats.
Y2K compliant programs and standards must continue to work with Y10K
dates before the year 10,000. Y10K compliant programs can gradually
be developed over time and coexist with non-Y10K compliant programs.
2.2 Simplicity and Efficiency
Y10K dates must allow dates after 10,000 to be easily identified.
Within a program, there must be a simple procedure for recognizing
the Y10K dates and distinguishing them from legacy dates.
2.3 Lexical Sorting
Y10K dates must be sortable lexically based on their ASCII
representation. The dates must not require specialized libraries or
procedures.
2.4 Future Extensibility
Y10K dates must support arbitrary precision dates, and should support
dates extending arbitrarily far into the future and past. Y10K dates
from different eras and with different precisions must be directly
comparable and sortable.
2.4.1 Environmental Considerations
The known universe has a finite past and future. The current age of
the universe is estimated in [Zebu] as between 10 ** 10 and 2 * 10 **
10 years. The death of the universe is estimated in [Nigel] to occur
in 10 ** 11 - years and in [Drake] as occurring either in 10 ** 12
years for a closed universe (the big crunch) or 10 ** 14 years for an
open universe (the heat death of the universe).
In any case, the prevailing belief is that the life of the universe
(and thus the range of possible dates) is finite.
2.4.2 Transcending Environmental Considerations
However, we might get lucky. So, Y10K dates are able to represent
any possible time without any limits to their range either in the
past or future.
Y10K compliant programs MAY choose to limit the range of dates they
support to those consistent with the expected life of the universe.
Y10K compliant systems MUST accept Y10K dates from 10 ** 12 years in
the past to 10 ** 20 years into the future. Y10K compliant systems
SHOULD accept dates for at least 10 ** 29 years in the past and
future.
3 Syntax Overview
The syntax of Y10K dates consists of simple, printable ASCII
characters. The syntax and the characters are chosen to support a
simple lexical sort order for dates represented in Y10K format. All
Y10K dates MUST conform to these rules.
Every Y10K date MUST begin with a Y10K year. Following the year,
there MAY be an arbitrary sequence of digits. The digits are
interpreted as MMDDHHMMSSmmmuuunnnpppfff... (month, day, hour,
minute, second, milli-second, micro-second, nano-second pico-second,
femto-second, etc. - moving left to right in the date, digits always
decrease in significance).
All dates and times MUST be relative to International Atomic Time
(TAI) [NRAO].
When comparing dates, a date precedes every other date for which it
is a prefix. So, the date "19990401000000" precedes the date
"19990401000000000". In particular, dates with the format YYYYMMDD
are interpreted to represent the exact instant that the day begins
and precede any other date contained in that day.
3.1 Years 1 - 9999
The current 4-digit year syntax covers all years from 1000 - 9999.
These years are represented as 4 decimal digits. Leading 0's MUST be
added to the years before 1000 to bring the year to 4 digits. Files
containing legacy pre-Y1K [Mike] dates will have to be converted.
3.2 Years 10,000 through 99,999
Four digits are not sufficient to represent dates beyond the year
9999. So, all years from 10,000 - 99,999 are represented by 5 digits
preceded by the letter 'A'. So, 10,000 becomes "A10000" and 99,999
dates with 5-digit years will follow all dates with 4-digit years
(for example, "A10000" will sort after "9999"). This gives us the
sort and comparison behaviour we want.
3.3 Years 100,000 up to 10 ** 30
By a simple generalization of 3.2, 6-digit years are preceded by the
letter 'B', 7-digit years by 'C', etc. Using just the 26 upper-case
ASCII characters, we can cover all years up to 10**30 (the last year
representable is "Z999999999999999999999999999999"). Again, since
the ASCII characters are sorted alphabetically, all dates sort
appropriately.
3.4 Years 10 ** 30 and beyond (Y10**30)
As discussed in 2.4.1, the end of the universe is predicted to occur
well before the year 10 ** 30. However, if there is one single
lesson to be learned from the current Y2K problems, it is that
specifications and conventions have a way of out living their
expected environment. Therefore we feel it is imperative to
completely solve the date representation problem once and for all.
3.4.1 Naive Approach for Y10**30 Problem
The naive solution is to prepend a single '^' (caret) - caret sorts
after all letters in the ASCII order) before all years from 10 ** 30
to 10 ** 56. Thus the year "Z999999999999999999999999999999" is
followed by the year "^A1000000000000000000000000000000". Similarly,
all years from 10 ** 56 to 10 ** 82 get one more caret. So, the year
"^Z99999999999999999999999999999999999999999999999999999999" is
followed by the year
"^^A100000000000000000000000000000000000000000000000000000000". This
scheme can be extended indefinitely by prepending one addition caret
for each additional factor of 10 ** 26 in the range of the year.
In this approach, the number of digits in a date that are used to
represent the year is simply:
26 * http://www.umsl.edu/~bwilking/assign/drake.html
[Microsoft] SNMP SysUpTime Counter Resets After 49.7 Days
http://support.microsoft.com/support/kb/articles/Q169/8/47.asp
[Mike] Y1K http://lonestar.texas.net/~mdlvas/y1k.htm
[Nigel] Nigel's (en)lighening tour of Thermodynamics for
Economists ;-) http://www.santafe.edu/~nigel/thermo-
primer.html
[NRAO] Astronomical Times
http://sadira.gb.nrao.edu/~rfisher/Ephemerides/times.html
[RFC] Here are all the online RFCs. Note: this is a LONG menu.
http://info.internet.isi.edu/1s/in-notes/rfc/files
[UNIX] Year 2000 Issues http://www.rdrop.com/users/caf/y2k.html
[Wilborne] PktCDateLig
http://www3.gamewood.net/mew3/pilot/pocketc/pktcdate/index.html
[YUCK] Y10K Unlimited Consulting Knowledgebase
http://www.loyd.net/y10k/index.html
[Zebu] The Search for H0
http://zebu.uoregon.edu/1997/ph410/l6.html
11 Authors' Addresses
Steve Glassman
Compaq Systems Research Center
130 Lytton Avenue
Palo Alto, CA 94301 USA
Phone: +1 650-853-2166
EMail: steveg@pa.dec.com
Mark Manasse
Compaq Systems Research Center
130 Lytton Avenue
Palo Alto, CA 94301 USA
Phone: +1 650-853-2221
EMail: msm@pa.dec.com
Jeff Mogul
Compaq Western Resarch Lab
250 University Avenue
Palo Alto, CA 94301 USA
Phone: +1 650-617-3300
EMail: mogul@pa.dec.com
12. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Please report problems with the web pages to the maintainer