Time Zones, Midnight and Daylight Saving

Time is the one thing this software is about, and it is where products are most consistently wrong.

Shifts that cross midnight

Which day does a shift from 22:00 to 06:00 belong to?

Answers differ legitimately: the start day for attendance, the actual day for daily hour limits, the pay period rule for payroll.

Products commonly pick one and hide it. Ask which, and whether it is configurable.

Test it: record a crossing shift and look at the daily totals, the weekly total and the export. If all three agree, the product has thought about it.

Daylight saving

Two clock hours vanish or repeat once a year, and both directions cause problems.

In spring, a shift from 01:00 to 09:00 is seven hours, not eight. A system storing local times without offsets will pay eight.

In autumn, the same shift is nine hours. Some systems pay eight and the worker disputes it.

Storing instants with offsets solves it; storing local wall-clock time does not.

Ask how times are stored, and test the transition explicitly. It is the single best test of whether the developers understood the domain.

Multiple zones

A distributed workforce needs each person's own zone, not the company's.

Reports need a stated zone, or two people reading the same figure see different days.

Payroll needs the zone the employment contract specifies, which is not always where the person is sitting.

Ask which zone each of these uses, and whether it can differ per person, per report and per pay group.

The related trap: the week boundary

Weeks start on different days by jurisdiction and agreement, and overtime thresholds attach to them.

A product with a fixed week start cannot serve two pay groups with different weeks, and this only shows up at the first overtime calculation.

Testing all of it

Four entries, and they find most of what is wrong.

A shift crossing midnight.

A shift across the spring transition.

A shift across the autumn transition.

A person in a zone different from the company's, whose entry falls near midnight.

Run each through to the payroll export, not just the on-screen total. The screen and the export disagree more often than anyone expects, and the export is what pays people.

Four entries that find most of it

The test set, and it takes ten minutes.

A shift crossing midnight.

A shift across the spring transition, which is seven hours and not eight.

A shift across the autumn transition, which is nine.

A person in a different zone whose entry falls near midnight.

Run each through to the payroll export, not just the on-screen total. Screen and export disagree more often than anyone expects, and the export is what pays people.

The week boundary

The related trap, and it is fatal for multi-jurisdiction deployments.

Weeks start on different days by jurisdiction and agreement, and overtime thresholds attach to them.

A product with a fixed week start cannot serve two pay groups with different weeks.

This only shows up at the first overtime calculation, which is after implementation.

Ask it directly during evaluation, because a surprising number of products cannot do it and none volunteers the limitation.

Use scheduled appointments as test data

Booking systems create clear timezone and boundary cases. This booking example helps test midnight, daylight-saving and source timestamps.