This article is more than 1 year old

Epoch-alypse now: BBC iPlayer flaunts 2038 cutoff date, gives infrastructure game away

Nobody expects the Linux malposition, do they, Michael Palin?

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.

iPlayer makes shows available until 18th January 2018

The cutoff date for some iPlayer programs is 18th January 2038

Way back when, the iPlayer service had a troubled start – initially requiring Windows XP, Windows Media Player 10+ and Internet Explorer to run – and chunks of it ended up being replaced with off-the-shelf tech in order to work for those annoying, smug Mac and Linux users.

Spot the expiry date. That date is as conspicuous to Unix beardies as 2000 was to DOS merchants. We reckon it's not just when Mr Palin's programme expires, but rather a whispered plea from the 32-bit Linux box held hostage somewhere behind it.

That fateful date pops up in lots of places: for fans of DOTA2, it's when an allegedly permanent ban expires. And if Atlassian JIRA users haven't suffered enough, a (now fixed) bug got to them, too.

Y2K was caused by programmers saving space by storing years as two digits – entirely justified just a few decades ago when saving two characters was an economy worth a measurable amount of money. The 2038 issue runs deeper, and it's not just a Linux problem.

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.

Also see this Twitter thread, where it's causing grief in pension funds. This one will run and run. But hey, there is good money to be made fixing it... for the next 16 years. Give or take a week.

We asked the BBC about iPlayer bug. It was not able to give us an explanation at the time of publication, but we will update this story if it does. If you can shed light on the issue, give us a shout here. ®

More about


Send us news

Other stories you might like