Posted on HN in 2126: 100 years ago, someone wrote a test for servo that included an expiry in 2126

I've got some tests in active code bases that are using the end of 32-bit Unix time as "we'll never get there". That's not because the devs were lazy, these tests date from when that was the best they could possibly do. They're on track to be cycled out well before then (hopefully this year), so, hopefully, they'll be right that their code "won't get there"... but then there's the testing and code that assumes this that I don't know about that may still be a problem.

"End of Unix time" is under 12 years now, so, a bit longer than the time frame of this test, but we're coming up on it.

	▲	bombcar 7 hours ago \| parent [-]
		I seem to recall much smugness on Slashdot around the "idiot winblows users limited by DOS y2k" and how the time_t was "so much better". Even then a few were prophesying that it would come bite us eventually ...

▲

yetihehe 8 hours ago | parent | prev [-]

Now I feel bad for using (system foundation timestamp)+100 years as end of "forever" ownership relations in one of my systems. Looking now, it's only 89 years left. I think I should use nulls instead.

▲

prerok 6 hours ago | parent [-]

Well, it won't be your problem /j

	▲	bombcar 4 hours ago \| parent [-]
		https://factorio.com/blog/post/fff-388 - they wanted to use a 64 bit int for the tick count, but Lua doesn't have one; so they used the one available and worked out when it would lose precision. "More than 2 million years seems to be enough for us to not be around any more when the bug reports start appearing."