At 0240 GMT* precisely on Friday, July 14, an epoch-defining moment will happen. And only real nerds – along with Reg readers – 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.” ®

Horology** notes

* UTC is just another way of saying Greenwich Mean Time, which, as ane fule no, is the one true way to tell the time.

** It means the study of time, not the study of ladies and/or gentlemen of the night.

Our thanks for the tipoff go to Reg reader Jamie (among others), who "thought some other saddos reading may be interested!" There's nothing sad about studying Unix timestamps, Jamie.