The midnight problem

Most attendance software stores an event against a calendar date. That works perfectly until a shift crosses midnight, at which point one continuous span of work is recorded as two fragments on two different dates.

The clock-in lands on Tuesday. The clock-out lands on Wednesday. Neither date now contains a complete shift, and both look wrong for different reasons.

What that actually breaks

The damage is rarely a visible error. It is a set of small wrong numbers that look plausible enough to go unchallenged.

  • Tuesday shows a clock-in with no clock-out, which reads as a missed punch rather than a night shift.
  • Wednesday shows a clock-out with no clock-in, which reads as an unexplained record.
  • Daily hour totals split across two dates, so neither matches the shift that was worked.
  • Overtime thresholds calculated per day fire on the wrong day, or not at all.
  • An in-progress overnight session gets flagged as an anomaly by anything looking for same-day pairs.

The fix is a working day, not a calendar day

The correct model is to attribute attendance to the working day a shift belongs to rather than the date the clock happened to show. A shift starting at 22:00 on Tuesday is Tuesday’s shift, and it stays Tuesday’s shift when it ends at 06:00 on Wednesday.

That requires the schedule to carry its own start and end times, so the system knows the span is intentional rather than an error. In SlidesClock, working times are set per weekday, and a shift that crosses midnight is kept together as one working day.

Grace periods behave differently at night

A grace period at the start of a night shift is measured against a start time that belongs to the previous calendar date. Systems that compute lateness against "today" get this wrong by exactly twenty-four hours, which usually presents as everybody on nights being flagged late, or nobody ever being flagged at all.

Because the grace period attaches to the scheduled shift rather than to a date, the arithmetic stays correct across the boundary.

Rotations, rest days and the week boundary

Teams that work nights rarely work only nights. A rota that runs earlies, lates and nights in the same week needs working times assigned per weekday and per employee, not a single pattern applied to everybody.

Rest days matter more here than anywhere else. A day nobody was scheduled to work is not an absence, and on a rotating rota that distinction is the difference between a usable report and one full of phantom absences. Absences derived from the schedule, rather than assumed from a Monday-to-Friday default, are what make the night side of a rota readable at all.

What to check before you commit

This is cheap to test and expensive to discover late. Before rolling any system out to a team that works nights, run one shift through it end to end.

  • Schedule a shift that crosses midnight, clock in and out, and look at how it is stored.
  • Check whether the hours appear on one working day or split across two dates.
  • Check whether a late clock-in on a night shift is flagged correctly against the scheduled start.
  • Check whether an in-progress overnight session is shown as in progress or as a missed clock-out.
  • Check what a rest day looks like in the report for someone on a rotating rota.

Why timezone belongs to the workplace

One more thing goes wrong at midnight: the timezone the day is read in. If a working day is bounded by whatever the reviewer’s browser thinks the time is, the same night shift can move between dates depending on who opens the report.

A company sets the timezone its attendance is read in, so the working day is the working day at that site. Combined with server-generated timestamps — which do not depend on the handset’s clock at all — that keeps an overnight record stable regardless of who is looking at it, and from where.