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.
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 ...
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.
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.
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 ...
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.
Well, it won't be your problem /j