Feeling old yet? Let the Reg ruin your day for you. We are now substantially closer to the 2038 problem (5,849 days) than it has been since the Year 2000 problem (yep, 8,049 days since Y2K).
Why do we mention it? Well, thanks to keen-eyed Reg reader Calum Morrison, we've spotted a bit of the former, and a hint of what lies beneath the Beeb's digital presence, when he sent in a snapshot that implies Old Auntie might be using a 32-bit Linux in iPlayer, and something with a kernel older than Linux 5.10, too.
That 2020 kernel release was the first able to serve as a base for a 32-bit system designed to run beyond 03:14:07 UTC on 19 January 2038. //
Like Y2K, it's easy to explain and fairly easy to fix: traditionally, UNIX stored the time as the number of seconds since January 1, 1970 – but they held it in a signed 32-bit value. That means that at seven seconds after pi o'clock in the morning of January 18th, 2038 (UTC), when it will be 2,147,483,647 (2³¹) seconds after the "epoch", the next time will be -2³¹: 20:45:52 in the evening of December 13th, 1901.
It has already been fixed in Linux and any other recent UNIX-ish OSes. The easy way is to move to a 64-bit value, giving a range of 292 billion years either way. That'll do, pig.
The fun bit is finding all the places it might occur, like this fun (and old and long-fixed) MongoDB bug. MongoDB stores the date correctly, Python stores the date correctly, but dates were passed from one to the other using a 32-bit value.
