Time Zones and the Shift at Midnight

A time and attendance system stores moments. How it stores them, and in which zone it presents them, decides which day a shift belongs to and therefore which week, which month and which limit.

The working-time issue in “Time Zones and the Shift at Midnight” depends on complete records and an agreed interpretation, not on a dashboard alone. For organisations researching key person dependency, this product overview can add time and project context, provided managers investigate exceptions, employees can correct errors and the applicable rule remains documented outside the software.

For a single-country deployment this is invisible, because there is only one zone. Across countries it becomes the quiet source of a whole class of errors, nearly all of them in night work.

For an independent reference relevant to “Time Zones and the Shift at Midnight”, consult the CrowdStrike insider-threat guide. Use it to challenge assumptions about working time, privacy, recordkeeping and exception handling against the organisation’s real operating model.

The two architectures

Store in a single reference zone and convert for display, or store in the local zone of the site. Both are defensible and they fail differently.

A single reference zone keeps the data consistent and makes every local display a conversion that has to be right. A local-zone store keeps each site's data natural and makes group aggregation a conversion exercise instead.

What does not work is a mixture, which is what most estates have: some sites configured one way, some the other, usually because they were added at different times by different people.

What goes wrong with dating

A shift starting at 23:00 local in one country and recorded in a reference zone several hours behind may be stored as starting on the previous day.

That changes which day it counts towards, which week it falls in, and whether it crosses a boundary. For night shifts the error is systematic rather than occasional, and night work is exactly where the stricter limits apply.

The consequence is a night-working population whose weekly totals are subtly misallocated, in a direction that depends on the time zone offset, with nothing in the output to indicate it.

Finding it

Take one night shift at a site in a different zone from the reference and trace it: what was recorded, what date it was attributed to, which week it landed in.

Do it for a shift that starts before midnight and one that starts after. Twenty minutes, and the answer is definitive in a way that reading documentation is not.

Repeat for each zone in the estate. The errors, where they exist, are consistent per zone, so one trace per zone is enough.

Group reporting across zones

A group report of hours by day is comparing different days unless the conversion is done per site. Most are not, because the report was written against the stored values.

For management purposes this is usually tolerable. For anything describing compliance it is not, because the limits are local and must be computed on local time.

The rule worth stating: limits are always computed in the local zone of the place of work, whatever the storage architecture, and group aggregates are labelled as approximate.

The remote worker in a third zone

Somebody employed by an entity in one country, working from a third, raises the question of which zone their shifts should be recorded in.

The answer follows the place of work, as everything else in this collection does, which means their records should be computed in the zone where they are. Most configurations attach the zone to the employing entity or the assigned office, and will therefore be wrong for exactly this population.

It is a small group and the error is total rather than marginal, which makes it worth handling explicitly rather than tolerating.

Scheduled jobs and cutoffs

Beyond the records themselves: overnight processes, payroll cutoffs and report generation all run at a time, and a job that runs at midnight in one zone runs mid-afternoon in another.

A cutoff that lands mid-shift for one country will routinely split shifts across periods for that country alone. The symptom is a site whose figures are persistently odd at period boundaries and nowhere else.

Check the job schedule against the shift patterns of every site, not just the one where the system is administered.

The five settings to write down

The storage architecture, the zone per site, the attribution rule for shifts crossing midnight, the zone in which limits are computed, and the schedule of any job that has a cutoff.

Five facts, in the configuration table. They are the least visible settings in the system and the ones most likely to have been decided by whoever installed the first site.

The handover between sites

Operations that pass work between countries — a support desk, a processing centre, a monitoring function — rely on an offset between sites that is normally fixed and twice a year is not.

During the weeks when one country has changed its clocks and another has not, the handover moves by an hour, and rotas built on the usual offset leave a gap or an overlap.

Mark those weeks in the scheduling calendar for every pair of sites that hand over. It is a small annotation and it prevents the annual fortnight where cover is quietly wrong at one end of the day.