Why a day is not always 24 hours long

A day is 24 hours in the same way that a month is 30 days: often enough to be a useful approximation, and wrong often enough to break things that depend on it. In any place that changes its clocks, two local days each year are not 24 hours long, and a surprising amount of software quietly assumes otherwise.

The short day and the long day

On the spring changeover the clocks jump forward by an hour, so that local day has 23 hours and one hour of local time never happens. Ask a system what time it was at 02:30 on that date in that zone and the honest answer is that there was no such moment. On the autumn changeover the clocks go back, the day has 25 hours, and one local hour happens twice, so 02:30 is genuinely ambiguous without extra information.

Not every change is exactly an hour, either. Lord Howe Island in Australia shifts by half an hour, and historically several places have made changes of other sizes. The safe assumption is not "an hour" but "whatever the time zone database says for that date".

Why this breaks date arithmetic

Adding "one day" to a local date and time by adding 86,400 seconds gives the wrong local reading on those two days: an event at 09:00 becomes 08:00 or 10:00. That is why calendar software adds days in the calendar rather than in seconds, and why an alarm set for 07:00 still rings at 07:00 the morning after a clock change.

The reverse error is just as common. Measuring a duration by subtracting two local readings gives an answer that is an hour out across a changeover. Durations should be computed on instants, in UTC, where every day really is 24 hours.

The rule that keeps you out of trouble

Do calendar work in calendar units, and duration work in instants:

• "Same time tomorrow" and "the 15th of next month" are calendar operations. Add days and months, and let the zone rules produce the instant.
• "In 24 hours" and "how long did this take" are duration operations. Work in UTC and convert to local only for display.
• Storing timestamps in UTC and rendering them locally keeps the two kinds of work separate, which is most of the battle.

Where you will notice it in ordinary life

Night shift pay is the classic example: the autumn shift really is an hour longer, and the spring shift an hour shorter, and payroll rules differ on whether that is paid. Overnight flights advertise a duration that does not match the difference between departure and arrival clocks. Sleep tracking apps report a strange night twice a year.

For counting days between dates none of this matters, which is the point: a calendar day count is unaffected by clock changes. The days between dates calculator counts calendar days, so its answer is stable across changeovers, and any hour-level arithmetic you need on top of it should be done on instants rather than on local readings.