9 working-hours mistakes that produce a wrong deadline without warning

An hours figure looks more precise than a days figure, so it gets challenged less. That is the wrong way round: hour arithmetic has more places to go wrong than day arithmetic, and its errors are smaller and harder to see.

Nine failures follow, each with the symptom that gives it away.

What to take away

Dividing elapsed hours by eight

A span from Friday afternoon to Monday morning can be 68 hours of elapsed time and four business hours. Dividing 68 by eight gives eight and a half, which is not close to four and is not a rounding difference.

The symptom is a report where weekend cases look enormous and weekday cases look right. If both quantities are genuinely wanted, compute both and label them, as set out under working hours.

Leaving the window without a zone

A window of 09:00 to 17:00 is not a fact until you say whose clock. A service answering callers in several regions will produce different answers for the same span if the window resolves in the caller's zone rather than the schedule's.

The symptom is answers that are consistently out by a whole number of hours for one group of users. Bind the zone to the schedule and reject a moment that arrives with no offset.

Storing an offset instead of a zone

An offset is a number and a zone is a rule. A schedule pinned to a fixed offset is right for part of the year and an hour out for the rest, in every region that changes its clocks.

Store a zone identifier from the tz database and let the library resolve the offset for each moment. The symptom of getting this wrong is an error that appears and disappears on two specific dates a year.

Assuming every day is 24 hours

In a zone that changes clocks, one local day is 23 hours and one is 25. A daytime window is unaffected: transitions happen in the small hours.

A window that spans them is not. A midnight to 06:00 window is five hours one day and seven the other. A schedule object that spans such a transition needs the zone stored on the calendar, not on the request.

Nothing warns you, because the wall-clock subtraction that gives six looks correct. The rules for a region are published by its timekeeping body, and the United States version is set out by NIST.

Forgetting to clip the partial days

The whole days in the middle of a span are a multiplication and are almost never wrong. The first and last days are clipped to the window, and that is where the errors live.

Two tests catch most of them. A span entirely outside the window must return zero, not a negative number and not the elapsed time. A span covering one full open day from before opening to after closing must return exactly the window length.

Treating a break as a subtraction

A lunch break modeled as an hour taken off the total is wrong for any span that does not cover the break. A span from 11:00 to 12:00 loses an hour it never had.

Model the day as a list of open intervals with the break as the gap between two of them. Then a span is clipped against each interval and nothing needs to know that a break exists.

Confusing a half day with half a day

A day that closes early is a day with a shorter window. It is not half a day of credit, and it is not a closure. Recording it as either produces a total that is right on average and wrong on every specific span.

The same distinction at day scale, where a partial closure has no representation at all, is under counting a month.

Letting the closure list live in the code

Closures are data with a publisher and a date of issue. Written into the calculation they cannot be audited, cannot be versioned, and cannot be different for two schedules in the same system.

Hold them as schedule exceptions and version them, as set out under how closure calendars are made and, where several jurisdictions layer, state and regional calendars.

Reporting an hours figure with no schedule attached

Two teams with different windows will produce different hour figures for the same span, and both are right. A figure quoted with no schedule and no version cannot be compared with anything, including its own value from last month.

The symptom is a metric that moves when a schedule changes and gets explained as a performance change. Record the schedule identifier and version beside every stored figure, the same discipline that software versioning applies to anything else that consumers pin to.

Common questions

Which of these is most common?

Dividing elapsed time by a day length. It is the only one that feels like a conversion rather than an assumption.

How do I test an hours implementation quickly?

Three spans: one entirely outside the window, one covering exactly one open day, and one crossing a weekend. Between them they catch clipping, the multiplication, and the rest-day rule.

Is an hour figure ever preferable to a day figure?

When the obligation is stated in hours it is the only honest unit. Converting it to days for reporting reintroduces the assumption you were trying to avoid.

Does any of this get simpler with a 24 hour schedule?

The window arithmetic does, because there is no clipping. The clock-change problem gets worse, because a 24 hour schedule genuinely has a 23 hour day and a 25 hour day.