Dates, as we have explored exhaustively, are hard. And yet, no matter how much we explore dates, and the myriad ways developers can completely screw them up, there are constantly new borders of date-related idiocy ahead of us.

The app Michael supported was running on a server running an Ubuntu version that was more than a little ancient, so as a test, he upgraded to the latest LTS version. That also included upgrades to the MySQL version they were running.

And right after doing the upgrade, errors like this started to appear: ERROR 1292 (22007): Incorrect datetime value: '2019-07-23 24:59:59' for column 'update_endDate'

Well, obviously, 24:59:59 is not a valid datetime value. Obviously, someone rolled a custom date-handling function, and something in the upgrade revealed an off-by-one error. Off-by-one bugs (or “OBOB” as one professor I had liked to call them) are common and easy.

Michael’s guess was technically correct. There was an off-by-one error, only it wasn’t in the code. It was in the original developer’s brain:

$temp_epoch_update_endDate=mktime(24,59,59,$TCMonth+6,$TCDay,$TCYear);
$EUMonth=date("m",$temp_epoch_update_endDate);
$EUDay=date("d",$temp_epoch_update_endDate);
$EUYear=date("Y",$temp_epoch_update_endDate);
$Cust_update_endDate="$EUYear-$EUMonth-$EUDay 24:59:59";

I’d say this code was designed for Mars, but even a Martian day is a smidge under 25 hours. The real WTF is that, somehow, this code worked at one time.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!