As per Relevance of the word represent, we have this rfc below:
Network Working Group S.
Request for Comments: 2550 M.
Category: Stinkards Track J.
Compaq Computer
1 April 1999
Y10K and
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
As we approach the end of the millennium, much attention has
paid to the so-called "Y2K" problem. Nearly everyone now regrets
short-sightedness of the programmers of yore who wrote
designed to fail in the year 2000. Unfortunately, the current
for Y2K lead inevitably to a crisis in the year 10,000 when
programs are again designed to fail
This specification provides a solution to the "Y10K" problem
has also been called the "YAK" problem (hex) and the "YXK"
(Roman numerals).
1. Introduction, Discussion, and Related
Many programs and standards contain, manipulate and maintain dates
Comparing and sorting dates is a common activity. Many
formats and standards for dates have been developed and all have
found wanting
Early date formats reserved only two digits to represent the
portion of a date. Programs that use this format make mistakes
dealing with dates after the year 2000. This is the so-called Y2
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-
years. This fix covers roughly the next 8,000 years (until the
9999) by which time, everyone seems convinced that all
programs will have been retired. This is exactly the faulty
and lazy programming practice that led to the current Y2K problem
Programmers and designers always assume that their code
eventually disappear, but history suggests that code and programs
often used well past their intended circumstances
The 4-digit year leads directly to programs that will fail in
year 10,000. This proposal addresses the Y10K problem in a
way that covers the full range of date and time format issues
1.1 Current
A large number of approaches exist for formatting dates and times
All of them have limitations. The 2-digit year runs into
next year. The 4-digit year hits the wall in the year 10,000.
16-bit year runs out in the year 65,536. A 32-bit counter for
number of seconds since 1970 [UNIX] wraps in 2038. A 32-bit
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
most common and a large number of existing standards and
are susceptible to them (section 7). These standards, and
proposals on their way, will lead to a serious world-wide
unless efforts are made now to correct the computing, government,
business communities
Already, a small cottage industry is popping up to deal with the Y10
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
At the time of this writing, only one proposal [Wilborne]
deals with the Y10K problem. In that proposal, dates are
as decimal numbers with the dates compared numerically. The
format is simply YYYYYMMDD - i.e. 5-digit years
To allow numerical comparison of dates, this representation
a completely fixed representation for the date. There can be
optional fields, the date resolution is limited to the granularity
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
While sufficient for the specific Y10K problem, this solution
limited. Even if extended for 6-digit years, it fails on 32-
systems (and future 32-bit system emulators) after the
represented by the number 2147481231 (December 31, 214748) leading
a Y214749 problem. Similarly, 64-bit and 128-bit systems also
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
The granularity problems of a fixed format date can be improved
extending the date format to include greater precision in the date
However, since numerical comparison of dates requires a
representation date, an extended format can not provide
resolution for all foreseeable needs
For instance, if the precision were extended to the femto-
range the date format would become
(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.
to 1.2.2, the 32-bit and 64-bit forms of the date are
exceeded, while the 128-bit version would be viable - expiring
December 31, 17,014,118,346,046.
1.2.3.1 Extrapolation of Future Granularity
However, a simple extrapolation of Moore's law shows that
femto-second resolution will soon be inadequate. Projecting
CPU clock speeds forward, a femto-second clock speed will be
in only 30 years. And, by the year 10,000 the projected clock
of the Intel Pentium MMDCLXVI (TM) will be approximately 10 ** (-
1609) seconds
This discussion clearly shows that any fixed-format,
representation of a date is likely to be insufficiently precise
future uses
1.2.3.2 Floating Point Is No
The temptation to use floating point numbers to represent
should be avoided. Like the longer fixed-format,
representations of the date, floating point representations
delay the inevitable time when their range is exceeded. In addition
Glassman, et. al. Informational [Page 3]
RFC 2550 Y10K and Beyond 1 April 1999
the well known problems of real numbers - rounding, de-normalization
non-uniform distribution, etc. - just add to the problems of
with dates
2 Structure of Y10K
Any Y10K solution should have the following characteristics
2.1
The format must be compatible with existing 4-digit date formats
Y2K compliant programs and standards must continue to work with Y10
dates before the year 10,000. Y10K compliant programs can
be developed over time and coexist with non-Y10K compliant programs
2.2 Simplicity and
Y10K dates must allow dates after 10,000 to be easily identified
Within a program, there must be a simple procedure for
the Y10K dates and distinguishing them from legacy dates
2.3 Lexical
Y10K dates must be sortable lexically based on their
representation. The dates must not require specialized libraries
procedures
2.4 Future
Y10K dates must support arbitrary precision dates, and should
dates extending arbitrarily far into the future and past. Y10K
from different eras and with different precisions must be
comparable and sortable
2.4.1 Environmental
The known universe has a finite past and future. The current age
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
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
open universe (the heat death of the universe).
In any case, the prevailing belief is that the life of the
(and thus the range of possible dates) is finite
Glassman, et. al. Informational [Page 4]
RFC 2550 Y10K and Beyond 1 April 1999
2.4.2 Transcending Environmental
However, we might get lucky. So, Y10K dates are able to
any possible time without any limits to their range either in
past or future
Y10K compliant programs MAY choose to limit the range of dates
support to those consistent with the expected life of the universe
Y10K compliant systems MUST accept Y10K dates from 10 ** 12 years
the past to 10 ** 20 years into the future. Y10K compliant
SHOULD accept dates for at least 10 ** 29 years in the past
future
3 Syntax
The syntax of Y10K dates consists of simple, printable
characters. The syntax and the characters are chosen to support
simple lexical sort order for dates represented in Y10K format.
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
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
decrease in significance).
All dates and times MUST be relative to International Atomic
(TAI) [NRAO].
When comparing dates, a date precedes every other date for which
is a prefix. So, the date "19990401000000" precedes the
"19990401000000000". In particular, dates with the format
are interpreted to represent the exact instant that the day
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
added to the years before 1000 to bring the year to 4 digits.
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
9999. So, all years from 10,000 - 99,999 are represented by 5
preceded by the letter 'A'. So, 10,000 becomes "A10000" and 99,999
Glassman, et. al. Informational [Page 5]
RFC 2550 Y10K and Beyond 1 April 1999
becomes "A99999". Since 'A' follows '9' in the ASCII ordering,
dates with 5-digit years will follow all dates with 4-digit
(for example, "A10000" will sort after "9999"). This gives us
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
letter 'B', 7-digit years by 'C', etc. Using just the 26 upper-
ASCII characters, we can cover all years up to 10**30 (the last
representable is "Z999999999999999999999999999999"). Again,
the ASCII characters are sorted alphabetically, all dates
appropriately
3.4 Years 10 ** 30 and beyond (Y10**30)
As discussed in 2.4.1, the end of the universe is predicted to
well before the year 10 ** 30. However, if there is one
lesson to be learned from the current Y2K problems, it is
specifications and conventions have a way of out living
expected environment. Therefore we feel it is imperative
completely solve the date representation problem once and for all
3.4.1 Naive Approach for Y10**30
The naive solution is to prepend a single '^' (caret) - caret
after all letters in the ASCII order) before all years from 10 ** 30
to 10 ** 56. Thus the year "Z999999999999999999999999999999"
followed by the year "^A1000000000000000000000000000000". Similarly
all years from 10 ** 56 to 10 ** 82 get one more caret. So, the
"^Z99999999999999999999999999999999999999999999999999999999"
followed by the
"^^A100000000000000000000000000000000000000000000000000000000".
scheme can be extended indefinitely by prepending one addition
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
represent the year is simply
26 * + ASCII() - ASCII('A') + 5
Note: this algorithm is provided for informational purposes only
to show the path leading to the true solution. Y10K dates MUST
use this format. They MUST use the format in the next section
Glassman, et. al. Informational [Page 6]
RFC 2550 Y10K and Beyond 1 April 1999
3.4.2 Space Efficient Approach for Y10**30
The solution in 3.4.1 is not a space efficient format for giving
number of digits in the year. The length of the prefix
linearly in the length of the year (which, itself,
logarithmically over time). Therefore, Y10K format dates use
improved, more compact encoding of the number of digits in the year
3.4.2.1 Years 10 ** 30 to 10 ** 56
As in 3.4.1, a single '^' and letter precede the year
3.4.2.2 Years 10 ** 56 to 10 ** 732
The year is preceded by two carets ("^^") and two letters.
letters create a two digit, base 26 number which is the number
digits in the year minus 57. So, the
"^Z99999999999999999999999999999999999999999999999999999999"
followed by the
"^^AA100000000000000000000000000000000000000000000000000000000".
last representable year with two carets is the year (10 ** 732) - 1
and is "^^ZZ999..999" (i.e. two carets and two Z's, followed by 732
consecutive 9's).
The formula for the number of digits in the year is, based on the
digit prefix is
26 * (ASCII() - ASCII('A')) +
ASCII() - ASCII('A') + 57
3.4.2.3 Years 10 ** 732 to 10 ** 18308
The next block of years has the number of digits given by
carets ("^^^") followed by three letters forming a three-digit,
26 number. The number of digits in the year is given by the formula
676 * (ASCII() - ASCII('A')) +
26 * (ASCII() - ASCII('A')) +
ASCII() - ASCII('A') + 733
3.4.2.4 General Format for Y10K
In general, if there is at least one letter in a Y10K year,
number of the digits in the year portion of the date is given by
formula
base26(fib(n) letters) + y10k(n
Glassman, et. al. Informational [Page 7]
RFC 2550 Y10K and Beyond 1 April 1999
Where "n" is the number of leading carets and the fig, base26
y10k functions are defined with the following recurrence relations
fib(n) is the standard Fibonacci sequence with
fib(0) = 1
fib(1) = 1
fib(n+2) = fib(n) + fib(n+1)
base26(m letters) is the base 26 number represented by m
A-Z
base26(letter) = ASCII() - ASCII('A')
base26(string letter) = 26 * base26(string) + base26(letter
y10k(n) is the necessary fudge factor to align the
properly
y10k(0) = 5
y10k(n+1) = 26 ** fib(n) + y10k(n
If the year does not have at least one letter in the year, then
number of digits in the year is
4
This year format is space-efficient. The length of the prefix
number of digits in the year only grows logarithmically with
number of digits in the year. And, the number of carets
the prefix only grows logarithmically with the number of digits
the prefix
3.5 B.C.E. (Before Common Era)
Now that have a format for all of the years in the future, we'll
on the "negative" years. A negative year is represented in "Y10K
complement" form. A Y10K-complement year is computed as follows
1) Calculate the non-negative Y10K year string as in 3.4.2.4.
2) Replace all letters by their base 26 complement. I.E. A -> Z,
-> Y, ... Z -> A
3) Replace all digits in the year portion of the date by their
10 complement. I.E. 0 -> 9, 1 -> 8, ... 9 -> 0.
4) Replace carets by exclamation points ('!').
5) Four-digit years are pre-pended with a slash ('/')
Glassman, et. al. Informational [Page 8]
RFC 2550 Y10K and Beyond 1 April 1999
6) Years that don't now begin with an exclamation point or slash
pre-pended with a star ('*'). (This rule covers the negative 5-
31 digit years).
For example, the year 1 BCE is represented by "/9998".
conversion is accomplished by applying rules
1) Calculate the non-negative Y10K year ("1" -> "0001")
2) Complement the digits ("0001" -> "9998")
3) Four-digit numbers get a leading slash
The earliest four-digit BCE year (9999 BCE) becomes "/0000" and
year before that (10000 BCE) becomes "*Z89999". The earliest 5-
BCE year (99999 BCE) is "*Z00000". And the year before that (100000
BCE) is "*Y899999". And so on
These rules give the desired sort order for BCE dates. For example
the following dates get translated and sorted as
Jun 6, 200 BCE /97990606
199 BCE /9800
Jan 1, 199 BCE /98000101
3.6 Restrictions on Y10K
There are no restrictions on legal values for Y10K dates. Y10
compliant programs MUST accept any syntactically legal Y10K date as
valid date. A '0' can be appended to the end of any Y10K date
yielding an equivalent date that sorts immediately after the
date and represents the instant after the original date
The following are all valid representations (in sorted order) of
first instant of A10000:
A
A10000
A1000001
A100000101000000
A1000001010000000000000000000000
Similarly, the following are all valid Y10K dates (in sorted order
for the time after the last instant of the A99999 and before
first instant of B100000:
A999991231250000
A999991232
A999992
A9999999999
A99999999990000000000000
Glassman, et. al. Informational [Page 9]
RFC 2550 Y10K and Beyond 1 April 1999
4
The following ABNF [Crocker] gives the formal syntax for Y10K years
The initial characters definitions are given in their
collation (ASCII) order
exclamation = '!'
star = '*'
slash = '/'
digit = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
letter = A | B | C | D | E | F | G | H | I | J | K | L | M |
N | O | P | Q | R | S | T | U | V | W | X | Y |
caret = '^'
year = [*(caret | exclamation) | star | slash ] [ *letter ]
*
month = 2
day = 2
hour = 2
minute = 2
second = 2
fraction = *
date = year [ month [ day [ hour [ minute [ second [
]]]]]]
5 Open
There are a number date comparison problems that are beyond the
of this specification
1) Dates from different calendar systems can not be
compared. For instance, dates from the Aztec, Bhuddist, Jewish
Muslim, and Hittite calendars must be converted to a
calendar before comparisons are possible
2) Future re-numberings of years are not covered. If, and when,
new "Year 0" occurs and comes into general use, old dates
have to be adjusted
3) Continued existence of Earth-centric time periods (year, day
etc.) are problematical past the up-coming destruction of
solar system (5-10 billion years or so). The use of atomic-
helps some since leap seconds are no longer an issue
Glassman, et. al. Informational [Page 10]
RFC 2550 Y10K and Beyond 1 April 1999
4) Future standards and methods of synchronization for inter
planetary and inter-galactic time have not been agreed to
5) Survivability of dates past the end of the universe is uncertain
6 Affected
A number of standards currently and RFCs use 4-digit years and
affected by this proposal
rfc2459: Internet X.509 Public Key
Certificate and CRL
rfc2326: Real Time Streaming Protocol (RTSP
rfc2311: ODETTE File Transfer
rfc2280: Routing Policy Specification Language (RPSL
rfc2259: Simple Nomenclator Query Protocol (SNQP
rfc2244: ACAP -- Application Configuration Access
rfc2167: Referral Whois (RWhois) Protocol V1.5
rfc2065: Domain Name System Security
rfc2060: Internet Message Access Protocol - Version 4rev
rfc1922: Chinese Character Encoding for Internet
rfc1912: Common DNS Operational and Configuration
rfc1903: Textual Conventions for Version 2 of
Simple Network Management Protocol (SNMPv2)
rfc1521: MIME (Multipurpose Internet Mail Extensions) Part One
rfc1123: Requirements for Internet hosts - application and
The following standards internally represent years as 16-bit
(0..65536) and are affected by this proposal
rfc2021: Remote Network Monitoring Management Information
Version 2 using SMIv
rfc1514: Host Resources
The following ISO standard is affected
ISO8601: International Date
8 Security
Y10K dates will improve the security of all programs where they
used. Many errors in programs have been tracked to overflow
parsing illegal input. Programs allocating fixed size storage
dates will exhibit errors when presented with larger dates.
errors can be exploited by wily hackers to compromise the security
systems running these programs. Since Y10K dates are
length strings, there is no way to make them overflow
Glassman, et. al. Informational [Page 11]
RFC 2550 Y10K and Beyond 1 April 1999
In addition, positive Y10K dates are easy to compare and less error
prone for humans. It is easier to compare the three projected end
the universe dates - "H100000000000", "I1000000000000"
"K100000000000000" - by looking at the leading letter than
counting the 0's. This will reduce inadvertent errors by people
This advantage will become more noticeable when large dates are
common
Unfortunately, negative Y10K dates are a bit more difficult
decipher. However, by comparing the current age of the universe
its projected end, it is obvious that there will be many
positive dates than negative dates. And, while the number
negative dates for human history is currently greater than the
of positive dates, the number of negative dates is fixed and
number of positive dates is unbounded
9
It is not too early to aggressively pursue solutions for the Y10
problem. This specification presents a simple, elegant,
efficient solution to this problem
10
[Crocker] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[Drake] Review for the Drake
http://www.umsl.edu/~bwilking/assign/drake.
[Microsoft] SNMP SysUpTime Counter Resets After 49.7
http://support.microsoft.com/support/kb/articles/Q169/
8/47.
[Mike] Y1K http://lonestar.texas.net/~mdlvas/y1k.
[Nigel] Nigel's (en)lighening tour of Thermodynamics
Economists ;-) http://www.santafe.edu/~nigel/thermo
primer.
[NRAO] Astronomical
http://sadira.gb.nrao.edu/~rfisher/Ephemerides/times.
[RFC] Here are all the online RFCs. Note: this is a LONG menu
http://info.internet.isi.edu/1s/in-notes/rfc/
[UNIX] Year 2000 Issues http://www.rdrop.com/users/caf/y2k.
Glassman, et. al. Informational [Page 12]
RFC 2550 Y10K and Beyond 1 April 1999
[Wilborne]
http://www3.gamewood.net/mew3/pilot/pocketc/pktcdate
index.
[YUCK] Y10K Unlimited Consulting
http://www.loyd.net/y10k/index.
[Zebu] The Search for H
http://zebu.uoregon.edu/1997/ph410/l6.
11 Authors'
Steve
Compaq Systems Research
130 Lytton
Palo Alto, CA 94301
Phone: +1 650-853-2166
EMail: steveg@pa.dec.
Mark
Compaq Systems Research
130 Lytton
Palo Alto, CA 94301
Phone: +1 650-853-2221
EMail: msm@pa.dec.
Jeff
Compaq Western Resarch
250 University
Palo Alto, CA 94301
Phone: +1 650-617-3300
EMail: mogul@pa.dec.
Glassman, et. al. Informational [Page 13]
RFC 2550 Y10K and Beyond 1 April 1999
12. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Glassman, et. al. Informational [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
