Your time clock may be computing overtime on the wrong day

A time clock has one job that nobody thinks about until it goes wrong: deciding which day a punch belongs to. Get that wrong and the hours still look right — the totals reconcile, the week adds up, nothing on the timesheet looks broken — but daily overtime silently vanishes. It is the most expensive rounding error in hospitality payroll, and it is almost invisible from the outside.

Where the day breaks

Most software stores timestamps in UTC. That is correct and sane. The bug appears one step later, when something has to answer “which day was this?” and answers it in UTC rather than at the hotel.

For a US property, UTC is already tomorrow from late afternoon onward:

So a front desk agent who works 2:00 PM to 10:00 PM Tuesday — one continuous eight-hour shift — is recorded as four hours Tuesday and four hours Wednesday. Nothing is missing. The week’s total is still correct. But the day has been cut in half.

Why that costs money

It costs money in states with a daily overtime threshold. Federal law (FLSA) only requires overtime past 40 hours in a week, but several states add a daily rule — California and Alaska past 8 hours in a day, Nevada past 8 for lower-wage employees, Colorado past 12, among others. Check your own state’s rule; they differ in the details and they change.

Under a daily-8 rule, that ten-hour Tuesday shift should earn two hours of overtime. Split across two UTC dates, it becomes a five-hour day and a five-hour day. Neither half crosses eight. The overtime the employee actually earned is never calculated at all.

Nobody complains, because nothing looks wrong. The hours are all there. Only the grouping is wrong, and grouping is the one thing nobody audits.

The same split quietly distorts everything else you compute per day: labor cost per occupied room, housekeeping minutes per room, the daily labor report you use to decide tomorrow’s schedule. All of them read a “day” that isn’t your day.

The ten-minute check

You don’t need to read anyone’s source code to test this. Pick a property, then:

1. Find a real evening shift that started before and ended after 8:00 PM local — a swing shift or a late housekeeping close.
2. Open the day view in your time system for that date.
3. Check the total. If the evening hours are missing from that day and appear on the next one, your system is grouping in UTC.

A faster version if you have a test property: clock someone in at 9:00 PM local and look at which date the punch lands on. If it shows tomorrow, you have your answer.

Then check the seams, because that is where it shows:

• Overtime, if your state has a daily threshold.
• Pay period boundaries — a period ending “the 15th” that actually ends at 8:00 PM on the 15th moves hours into the wrong check.
• Any per-day metric: labor per occupied room, daily labor cost, housekeeping minutes.

What to ask a vendor

This is hard to see from a demo, because a demo is run in the middle of the afternoon, when UTC and local still agree. Three questions get you a straight answer:

1. “Where is a property’s timezone stored?” If the answer is a single company-wide setting, or “we use the browser’s timezone,” the system cannot be right for two properties in different zones at once. The timezone has to live on the property record.
2. “If I clock someone in at 9 PM, which day does the punch land on?” Ask them to do it in the demo environment. It takes thirty seconds and it is not a question that can be answered persuasively in the abstract.
3. “How is a pay period boundary resolved?” A period ending on the 15th has to end at midnight at the hotel. Ask what happens to an 8 PM punch on the 15th.

A vendor who has thought about this will answer immediately and specifically, because it is a decision they had to make explicitly. Vagueness here is itself the answer.

What correct looks like

There is exactly one rule, and it is short: a calendar day belongs to the property, never to UTC and never to the browser. Every question of the form “what happened today at this hotel?” gets resolved in that hotel’s own timezone, at the hotel — not on the server, and not on the laptop of whoever happens to be looking.

That matters more than it sounds for a portfolio. If you run properties in Phoenix and Atlanta, “today” is genuinely two different windows, and a system that picks one timezone for the whole company is wrong for at least one of them every single day. The timezone has to live on the property, not in a global setting.

This is a rule we hold ourselves to in ProfitClock: every date a property sees — punches, overtime, pay periods, the kiosk’s own clock, the daily labor report — is resolved in that property’s timezone. We treat it as a payroll-correctness rule rather than a formatting preference, because that is what it is.

If you’d like a second pair of eyes on your current numbers, book a demo and bring a real week of timesheets — the evening shifts are where it shows up first. Or read what hotel scheduling software costs if you’re still mapping the landscape.