At 0240 GMT* precisely Today, Friday, July 14, an epoch-defining moment happened. And only real nerds – will know what that moment is.
The Unix epoch will pass its 1.5 billionth second in the small hours. A quick check with everyone’s favourite scripting language, Perl, confirms this:$ perl -MDateTime -lE'say DateTime->from_epoch( epoch => 1_500_000_000 )' 2017-07-14T02:40:00
The epoch began at 0000 on 1 January 1970, the point from which all Unix timestamps are calculated. Although each individual second is counted from then (and converted into human-readable format for display purposes), leap seconds are not counted.
Back in February 2009 the epoch passed second number 1,234,567,890. As our scribe Dan Goodin pointed out shortly before the momentous moment: “Can this thing continue on forever with no tweaking, or will it eventually need an overhaul?”
The answer is yes, an overhaul is needed. Come 03:14:07 UTC on 19 January 2038, the Unix timestamp will run into a not inconsiderable snag: the epoch, as a 32-bit signed integer, will overflow to a massive negative number and start counting up to zero. Software vulnerable to this Year 2038 headache will think reality has lurched back to 13 December 1901. This will lead to a similar situation to the Y2K bug, which has its origins in old software’s date and time groups being stored and expressed in the format dd-mm-yy.
Attempts to mitigate the Y2K bug indirectly led to a fire station burning down, caused a power cut in London and, terribly sadly, caused “extreme problems with the Inland Revenue.”