RFC 2550

Y10K and Beyond

📅 published April 1999, from ietf

RFC 2550: Y10K and Beyond 💖

Okay bestie, this is RFC 2550, and it's called Y10K and Beyond 🎀. It came out of the Network Working Group on 1 April 1999 (yes, April Fools 🙈), and its category is Stinkards Track 🧚. It was written by S. Glassman, M. Manasse, and J. Mogul, all from Compaq Computer Corporation. It doesn't list anything it obsoletes or updates, so it's a solo-ish main character with no baggage 💅✨.

Status of This Memo 📝

This memo gives information to the Internet community 🌈. It doesn't specify any kind of Internet standard, and it's totally free to share with anyone, no limits 🫶.

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

Abstract 🌸

Okay so as we get closer to the end of the millennium, everyone's been obsessed with the "Y2K" problem 😭. Honestly, everyone regrets how short-sighted the old programmers were when they wrote programs designed to fail in the year 2000 💀. The big catch is that the current Y2K fixes lead straight into a crisis in the year 10,000, when the programs are, once again, designed to fail 🙈.

This spec is the fix for the "Y10K" problem. It's also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals) 🔥. Iconic naming, no notes 👑.

So basically, tons of programs and standards store, change, and keep track of dates. Comparing and sorting dates is a super common thing to do 💅. There have been so many different date formats and standards over the years, and every single one has been found lacking 😭.

The early date formats only gave two digits to the year part 🙈. Programs using that format start messing up once you get past the year 2000. That's the so-called Y2K problem 💀.

The most popular Y2K fix was switching to 4-digit years 🎀. That fix covers roughly the next 8,000 years (until the year 9999), and by then everyone seems sure that all current programs will have been retired 🙃. Ngl, this is exactly the faulty thinking and lazy programming that caused the Y2K problem in the first place! Programmers always assume their code will eventually disappear, but history shows code and programs keep getting used well past what they were meant for 😤.

4-digit years lead right to programs that will fail in the year 10,000 ⭐. This proposal tackles the Y10K problem in a general way that covers the full range of date and time format issues 💖.

1.1 Current approaches 🍓

There are a bunch of ways to format dates and times, and every single one has 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 🫠. And a 32-bit counter for the number of milli-seconds since booting crashes a Windows (TM) PC in 49.7 days [Microsoft] 🔥.

In this spec, we focus on the Y10K problems, because they're the most common, and a huge number of existing standards and protocols are vulnerable to them (section 7) 👑. These standards, plus new proposals on the way, will cause a serious world-wide problem unless the computing, government, and business communities start fixing things now ⭐.

A little cottage industry is already popping up to handle the Y10K problem [YUCK] 🧚. We love to see it! In the coming years this effort can only get bigger and more important 🌈.

1.2 A Fixed Format Y10K Fix 💜

When this was written, only one proposal [Wilborne] directly deals with the Y10K problem 🎀. In that proposal, dates are written as decimal numbers, and they get compared numerically 🔢. The proposed format is just YYYYYMMDD, which means 5-digit years 💖.

To let dates be compared numerically, this representation needs a completely fixed format for the date 🙈. There can't be any optional fields, the date resolution is limited to one day, and this solution fails in the year 100,000 (Y100K) 💀.

1.2.2 Limitations of Numerical Comparison 🙃

Okay, this solution is enough for the specific Y10K problem, but it's still limited 😤. Even if it were extended to 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). That leads to a Y214749 problem 😭. 64-bit and 128-bit systems fail too, just 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 🔍

You can improve the granularity problems of a fixed format date by making the date format more precise 💅. But because comparing dates numerically needs a fixed representation, an extended format still can't provide enough resolution for every foreseeable need 🫠.

For example, if you extended the precision all the way 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) 🧚. Those extra 21 digits limit the set of dates you can represent 😵. Compared to 1.2.2, the 32-bit and 64-bit forms 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 🚀

Okay but a simple extrapolation of Moore's law shows that even femto-second resolution will soon be inadequate 😭. If you project current CPU clock speeds forward, a femto-second clock speed will be reached in only 30 years 🏃. And by the year 10,000, the projected clock speed of the Intel Pentium MMDCLXVI (TM) will be about 10 ** (-1609) seconds 🤯.

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

1.2.3.2 Floating Point Is No Solution 🚫

Please avoid using floating point numbers to represent dates 🙅. Like the longer fixed-format integer representations, floating point just delays the inevitable moment when their range is exceeded ⏳. On top of that, the well known problems of real numbers (rounding, de-normalization, non-uniform distribution, etc.) just pile onto 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 keep working with Y10K dates before the year 10,000 ✨. Y10K compliant programs can be developed gradually over time and coexist with non-Y10K compliant programs 🌸.

2.2 Simplicity and Efficiency 🧠

Y10K dates must make it easy to spot dates after 10,000 🔎. Inside a program, there must be a simple procedure for recognizing Y10K dates and telling them apart from legacy dates 🎀.

2.3 Lexical Sorting 📚

Y10K dates must be sortable lexically based on their ASCII representation 🔤. They must not need specialized libraries or procedures, which is so relieving 🙌.

2.4 Future Extensibility 🔮

Y10K dates must support arbitrary precision dates, and they 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, which is kind of a lot to process 🌌. 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) 💀.

Anyway, the prevailing belief is that the life of the universe (and therefore 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, with no limits to their range 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 is made of simple, printable ASCII characters 🔤. The syntax and the characters are picked to support a simple lexical sort order for dates in Y10K format 📚. Every single Y10K date MUST conform to these rules, no exceptions 💅.

Every Y10K date MUST begin with a Y10K year 🎀. After 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 through the date, the 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 they come before any other date contained in that day 🌅.

3.1 Years 1 - 9999 📅

The current 4-digit year syntax covers all years from 1000 to 9999 🎀. These years are written as 4 decimal digits. Leading 0's MUST be added to years before 1000 to bring them up 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 aren't enough to represent dates beyond the year 9999 🙈. So all years from 10,000 to 99,999 are written as 5 digits preceded by the letter 'A' ✨. For example, 10,000 becomes A10000 and 99,999 becomes A99999. Since 'A' follows '9' in ASCII ordering, all dates with 5-digit years will sort after all dates with 4-digit years (for example, A10000 sorts 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', and so on 🔤. Using just the 26 upper-case ASCII characters, we can cover all years up to 10**30 (the last year representable is Z999999999999999999999999999999) 👑. Again, because the ASCII characters are sorted alphabetically, all dates sort correctly 🧚.

3.4 Years 10 ** 30 and beyond (Y10**30) 🌠

As discussed in 2.4.1, the end of the universe is predicted to happen well before the year 10 ** 30 🌑. But if there's one big lesson from the current Y2K problems, it's that specifications and conventions have a way of outliving their expected environment 😭. So we feel it's imperative to completely solve the date representation problem once and for all 💅✨.

3.4.1 Naive Approach for Y10**30 Problem 🙈

okay so the naive solution is literally to slap a single ^ (caret) in front of every year from 10 ** 30 to 10 ** 56. caret sorts after all the letters in ASCII order, so it's the perfect little sorting gremlin 💅 Thus the year Z999999999999999999999999999999 is followed by the year ^A1000000000000000000000000000000. Similarly, all years from 10 ** 56 to 10 ** 82 get one more caret, so ^Z99999999999999999999999999999999999999999999999999999999 is followed by ^^A100000000000000000000000000000000000000000000000000000000. This scheme can keep going forever by adding one more caret for each extra factor of 10 ** 26 in the year 🌈

With this approach, the number of digits used to represent the year is:

26 * <number of '^'> + ASCII(<prefix letter>) - ASCII('A') + 5
Note: this algorithm is provided for informational purposes only and to show the path leading to the true solution. Y10K dates MUST NOT use this format. They MUST use the format in the next section. 🫶

3.4.2 Space Efficient Approach for Y10**30 Problem ✨

the 3.4.1 solution is NOT space efficient for saying how many digits are in the year 😭 The prefix length grows linearly with the length of the year (and the year itself only grows logarithmically over time), so Y10K dates use a much more compact way to encode the number of digits in the year 🦋

3.4.2.1 Years 10 ** 30 to 10 ** 56

same as 3.4.1, a single ^ and a letter come before the year 🌸

3.4.2.2 Years 10 ** 56 to 10 ** 732

the year gets two carets (^^) and two letters. Those two letters make a two digit, base 26 number, which is the number of digits in the year minus 57. So ^Z99999999999999999999999999999999999999999999999999999999 is followed by ^^AA100000000000000000000000000000000000000000000000000000000. The last year you can represent with two carets is (10 ** 732) - 1, written as ^^ZZ999..999 (two carets, two Z's, then 732 consecutive 9's) 💖

The formula for the number of digits in the year, based on the two letter prefix, is:

26 * (ASCII(<prefix letter1>) - ASCII('A')) +
      ASCII(<prefix letter2>) - ASCII('A') + 57

3.4.2.3 Years 10 ** 732 to 10 ** 18308

next up, three carets (^^^) followed by three letters, which form a three-digit, base 26 number. the number of digits in the year is:

676 * (ASCII(<prefix letter1>) - ASCII('A')) +
 26 * (ASCII(<prefix letter2>) - ASCII('A')) +
       ASCII(<prefix letter3>) - ASCII('A') + 733

3.4.2.4 General Format for Y10K Dates 👑

okay this is the big-brain part 🧠 In general, if there is at least one letter in a Y10K year, the number of digits in the year portion of the date is given by:

base26(fib(n) letters) + y10k(n)

where "n" is the number of leading carets, and the fib, base26 and y10k functions are defined by these 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 letters
A-Z:

base26(letter) =  ASCII(<letter>) - ASCII('A')
base26(string letter) = 26 * base26(string) + base26(letter)

y10k(n) is the necessary fudge factor to align the sequences
properly:

y10k(0) = 5
y10k(n+1) = 26 ** fib(n) + y10k(n)

If the year does not have at least one letter in it, then the number of digits in the year is:

4

this year format is space-efficient 🌟 The length of the prefix giving the number of digits in the year only grows logarithmically with the number of digits in the year. And the number of carets in front of the prefix only grows logarithmically with the number of digits in the prefix. literally so smart 😭

3.5 B.C.E. (Before Common Era) Years 🦖

now that we have a format for all the years in the future, we're going to tackle the "negative" years. A negative year is written in "Y10K-complement" form. To make a Y10K-complement year:

  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, B -> Y, ... Z -> A.
  3. Replace all digits in the year portion of the date by their base 10 complement. I.E. 0 -> 9, 1 -> 8, ... 9 -> 0.
  4. Replace carets by exclamation points (!).
  5. Four-digit years get pre-pended with a slash (/).
  6. Years that don't now begin with an exclamation point or slash get pre-pended with a star (*). (This rule covers the negative 5-31 digit years.)

For example, the year 1 BCE is /9998. The conversion works by applying the rules like this:

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 the year before that (10000 BCE) becomes *Z89999. The earliest 5-digit 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, these dates get translated and sorted like this:

Jun 6, 200 BCE            /97990606
199 BCE                   /9800
Jan 1, 199 BCE            /98000101

3.6 Restrictions on Y10K Dates 🚫

there are NO restrictions on legal values for Y10K dates. Y10K compliant programs MUST accept any syntactically legal Y10K date as a valid date. A 0 can be appended to the end of any Y10K date, which gives you an equivalent date that sorts right after the original and represents the instant after it 🍓

The following are all valid representations (in sorted order) of the first instant of A10000:

A1
A10000
A1000001
A100000101000000
A1000001010000000000000000000000

Similarly, the following are all valid Y10K dates (in sorted order) for the time after the last instant of A99999 and before the first instant of B100000:

A999991231250000
A999991232
A999992
A9999999999
A99999999990000000000000

4 ABNF 🎀

the following ABNF [Crocker] gives the formal syntax for Y10K years.

The initial character definitions are given in their lexical 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 | Z
caret       = '^'

year     = [*(caret | exclamation) | star | slash ] [ *letter ]
          *digit
month    = 2digit
day      = 2digit
hour     = 2digit
minute   = 2digit
second   = 2digit
fraction = *digit
date     = year [ month [ day [ hour [ minute [ second [ fraction
          ]]]]]]

5 Open Issues 🧐

there are a number of date comparison problems that are beyond the scope of this specification, bestie 💀

  1. Dates from different calendar systems can not be directly compared. For instance, dates from the Aztec, Bhuddist, Jewish, Muslim, and Hittite calendars must be converted to a common calendar before comparisons are possible.
  2. Future re-numberings of years are not covered. If, and when, a new "Year 0" occurs and comes into general use, old dates will have to be adjusted.
  3. Continued existence of Earth-centric time periods (year, day, etc.) are problematical past the up-coming destruction of the solar system (5-10 billion years or so). The use of atomic-time helps some since leap seconds are no longer an issue.
  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. the universe really said "we'll see" 🌌

6 Affected Standards 📚

a bunch of standards that currently use 4-digit years, plus RFCs, are affected by this proposal:

rfc2459: Internet X.509 Public Key Infrastructure
         Certificate and CRL Profile
rfc2326: Real Time Streaming Protocol (RTSP)
rfc2311: ODETTE File Transfer Protocol
rfc2280: Routing Policy Specification Language (RPSL)
rfc2259: Simple Nomenclator Query Protocol (SNQP)
rfc2244: ACAP -- Application Configuration Access Protocol
rfc2167: Referral Whois (RWhois) Protocol V1.5
rfc2065: Domain Name System Security Extensions
rfc2060: Internet Message Access Protocol - Version 4rev1
rfc1922: Chinese Character Encoding for Internet Messages
rfc1912: Common DNS Operational and Configuration Errors
rfc1903: Textual Conventions for Version 2 of the
         Simple Network Management Protocol (SNMPv2)
rfc1521: MIME (Multipurpose Internet Mail Extensions) Part One:

rfc1123: Requirements for Internet hosts - application and support

the following standards internally represent years as 16-bit numbers (0..65536) and are affected by this proposal:

rfc2021: Remote Network Monitoring Management Information Base
         Version 2 using SMIv2
rfc1514: Host Resources MIB

and this ISO standard is affected:

ISO8601: International Date Format

8 Security Considerations 🔐

Y10K dates will improve the security of all programs where they are used. Many errors in programs have been traced to overflow while parsing illegal input. Programs that allocate fixed size storage for dates will show errors when presented with larger dates, and these errors can be exploited by wily hackers to compromise the security of systems running these programs 🚨 Since Y10K dates are arbitrary length strings, there is no way to make them overflow.

Positive Y10K dates are also easy to compare and less error-prone for humans 🥹 It's easier to compare the three projected end-of-the-universe dates, H100000000000, I1000000000000 and K100000000000000, by looking at the leading letter than by counting the 0's. This will reduce inadvertent errors by people, and the advantage will become more noticeable when large dates are more common.

Unfortunately, negative Y10K dates are a bit harder to decipher. However, by comparing the current age of the universe to its projected end, it is obvious that there will be many more positive dates than negative dates. And while the number of negative dates for human history is currently greater than the number of positive dates, the number of negative dates is fixed and the number of positive dates is unbounded. the math is mathing 🧮💜

9 Conclusion 🌟

it is not too early to aggressively pursue solutions for the Y10K problem. This specification presents a simple, elegant, and efficient solution to this problem, and honestly? it's giving iconic 👑✨

10. References ✨

okay bestie, this is the reading list 📚 every source the spec leans on, with the links so you can go see the receipts 🧾

11. Authors' Addresses 🎀

these are the brilliant people behind this doc, and how to reach them 💌

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

legal stuff, but make it cute 🧾

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

okay so you're allowed to copy this document and share it with anyone 💖 you can also write derivative works that comment on or explain it, or that help people implement it, and publish and distribute those however you like, in whole or in part, with no restrictions of any kind. the one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 🫶

BUT the document itself can't be modified in any way. you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process have to be followed, or when it's being translated into a language other than English 🌈

these permissions are perpetual, and the Internet Society or its successors or assigns will never revoke them ✨

this document and the information in it are provided "AS IS", 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. 💀
📦 where this page comes from