RFC 2550 – Y10K and Beyond (1999)

[_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.

[cs-]

And then you would of course use a toolbox (or make one) that supports large dates, or even work with other time units (ie. D)

[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/ 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...