02 tools
Date & time
Unix timestamps and date arithmetic.
Where time calculations actually go wrong
Almost never in the arithmetic. They go wrong at the boundaries: a timestamp in seconds read as milliseconds, a UTC value displayed as if it were local, a date range counted inclusive when the contract meant exclusive, or a leap day that has no anniversary in three years out of four. Each of those produces a result that looks plausible and is wrong by hours or by a day — the hardest kind of bug to notice.
The two rules worth memorising
Store UTC, render local, and never store a local time without its offset. And identify a timestamp's unit from its magnitude before converting it: ten digits is seconds, thirteen milliseconds, sixteen microseconds. That check takes one glance and prevents most "the date is in 1970" incidents.
2038 is not theoretical
Any system still holding seconds in a signed 32-bit integer wraps on 19 January 2038. Most modern stacks are already 64-bit, but embedded devices, old databases and file formats are not — and the failure mode is silent.