

RFC 2550 – Y10K and Beyond (1999) - slyfocks
http://tools.ietf.org/html/rfc2550

======
_jomo
You can already hit these problems today. People always think about the
_current_ date, although there very valid are reasons to store future (or
past) dates.

For example, if you're are a scientist you might want to calculate where
planet xyz is in 100,000 years - and store that date on your computer, today.

~~~
perlgeek
One doesn't have to go that far. Mortgages, life insurance, annuity assurance
and the like can run for more than the mere 23 years that are between now and
2038.

Heck, I won't even be retired in 2038 if things continue to work as they do
now.

~~~
_jomo
Apparently it already caused trouble with AOLServer in 2006 [0] because there
was a database connection timeout of 1 billion seconds which hit the 32bit
limit.

[0]: [http://www.mail-
archive.com/aolserver@listserv.aol.com/msg09...](http://www.mail-
archive.com/aolserver@listserv.aol.com/msg09844.html)

------
polskibus
Please label this as 1999, April Fool's Day .

------
cs-
We're 16 days behind 1st of April, at the time of this writing...

~~~
peri
And should expect more novel NTP and time issues before it.

------
0942v8653
Also see: [http://longnow.org/about/](http://longnow.org/about/) which aims to
fix Y10K/YAK/YXK but unfortunately not Y100K/Y64K/YCK (yet anyway).

------
thomasfoster96
It's interesting seeing how Wikidata has been storing dates. They store things
like the time that the universe started as a date, which means the year is
about 11 digits.

JavaScript's Date object doesn't like such big dates - I don't think it works
with anything greater than a few hundred million years.

------
lorddoig
> A 32-bit counter for the number of seconds since 1970 [UNIX] wraps in 2038.

What's the bet this one actually causes problems

~~~
the8472
It already has:
[http://en.wikipedia.org/wiki/Year_2038_problem#Early_problem...](http://en.wikipedia.org/wiki/Year_2038_problem#Early_problems)

