Normally, I wouldn't have much to say about a simple "it's a mere arithmetic error" type of code sample. But this submission from Taylor adds an important factor: it's a basic arithmetic mistake in date handling code, in a legacy product that's been in use for decades. Oh, and it's written in Delphi.
ElapsedSeconds := Round( (Now - StartTime) * 24.0 * 60.0 * 60.0);
Days := ElapsedSeconds div 86400;
Hours := ElapsedSeconds mod 86400 div 3660;
Minutes := ElapsedSeconds mod 86400 mod 3660 div 60;
Seconds := ElapsedSeconds mod 86400 mod 3660 mod 60;
I'm not going to get too uppity about the bare constants in the first line. HOURS_PER_DAY
would help readability, but it's pretty clear what this line is doing: converting a number of days into a number of elapsed seconds.
The following lines then pick that number of seconds back apart into a more traditional timestamp- a number of whole days, a number of whole hours, a number of whole minutes, and finally a number of seconds.
I'm not going to pick on the idea that they should have just used some built-in functions for this, because upon some research, it doesn't look like Delphi has any sort of elegant date handling- dates are just represented as floats, so while you can format a date difference nicely, picking it apart for hours, minutes and seconds requires some sort of code like this.
No, the WTF here is that the number of seconds in an hour is wrong. There are 3600 seconds in an hour, not 3660. They've added an entire minute to every hour, making each day 24 hours and 24 minutes long.
And as you might gather from this being in Delphi, this code base doesn't exactly represent greenfield development. This bug has been in the code for some time. Everyone who used the product knew that these elapsed times were wrong, but decided to just manually edit their reports to include a fudge factor for timing.
All that said, it'd be nice to have an extra 24 minutes a day. I'd probably use it to sleep.