Once a services firm has people logging hours from more than two time zones, the old habit of "everyone just writes down what they worked" stops being reliable. Not because anyone is dishonest, but because a day boundary, a DST switch, or a client's local invoice date can all quietly shift an entry by an hour or land it on the wrong calendar day entirely. Below is how to actually fix that, not by asking people to think harder about time zones, but by changing what the system stores.
In this guide
Pick one internal clock and never argue about it again Stop tracking hours by "day," start tracking them by timestamp Timesheet approval windows that survive multiple zones Daylight saving time will break something if you let it Frequently asked questions
Pick One Clock and Never Argue About It Again
Every distributed team eventually has this argument: is the timesheet week Monday through Sunday in headquarters time, or in the employee's local time, or in the client's time? All three answers seem reasonable, which is exactly the problem. The fix isn't picking the "right" zone, it's separating what gets stored from what gets shown.
Store every time entry as a timestamp in Coordinated Universal Time (UTC). That single stored fact never changes no matter who looks at it or where they're sitting. Then display that same timestamp converted into whatever zone makes sense for the viewer: local time for the person logging it, headquarters time for the ops manager running payroll, and the client's own time zone on the invoice they receive. A 45-person IT services firm we've talked with runs delivery teams across Kraków, Manila, and Austin. Before they separated storage from display, "Tuesday's hours" meant three different 24-hour windows depending on who you asked. After, the underlying data is identical, only the label changes.
This sounds like a small technical detail, but it's the one decision that prevents almost every downstream dispute described in this article. If your current time tracking tool doesn't let you see this distinction (stored UTC value versus displayed local value), that's worth checking on the features page before you build workarounds on top of a tool that can't do it.
Stop Tracking Hours by "Day," Start Tracking Them by Timestamp
Most timesheet software still asks people to log "hours worked on this date" as a single number attached to a calendar day. That's fine until a shift crosses midnight in someone's local zone, or until a client in a different zone tries to reconcile which of their business days an entry actually belongs to. A support engineer in Manila working a shift that runs 11pm to 7am local time isn't doing anything unusual, but a day-based timesheet has no good way to represent that without either splitting the entry awkwardly or attaching the whole shift to whichever date felt closer.
The more durable approach is logging a start timestamp and an end timestamp, both stored in UTC, and letting duration and "which day this counts toward" be calculated values rather than something a person types in. This matters more than it sounds like it should:
- Duration comes from subtracting two UTC timestamps, never from subtracting two local wall-clock times, which breaks the moment a shift crosses a zone boundary or a DST change
- "Which day" is assigned by policy, not by feel, usually the day the shift started in the employee's home zone, applied the same way for every entry so payroll totals don't shift depending on who's reading the report
- Overnight and split shifts get logged as one entry, not artificially divided at midnight, which keeps the record matching what actually happened
- Client-facing invoices convert from the same stored timestamp, so a dispute over "which day was billed" can be settled by pointing at one unambiguous record instead of two conflicting local calendars
Timesheet Approval Windows That Survive Multiple Zones
A weekly approval deadline of "Friday at 5pm" means something different to everyone if your team spans more than three zones. For a manager in London, Friday 5pm is the end of the week. For a contractor in Manila, that deadline lands at midnight Saturday local time, well after most people have logged off for the weekend. Missed deadlines caused by this mismatch aren't a discipline problem, they're a design problem.
Set approval cutoffs relative to a fixed anchor zone (usually wherever your finance or ops lead sits) and then show every contributor their own personal deadline converted into their local time, with enough runway that "Friday 5pm London" doesn't quietly become "please submit while asleep" for someone eight zones east. Give a 24 to 48 hour buffer for anyone outside the anchor zone's business hours before the hard cutoff, and send the reminder in their local morning, not the anchor zone's morning.
The single fastest way to reduce late or wrong timesheets isn't a stricter policy, it's showing the deadline in the person's own clock. A rule that reads correctly only in headquarters time will get missed by everyone else, not because they're careless, but because they're doing the zone math in their head and getting it wrong on a Friday afternoon.
Firms that run this well tend to build the approval chain into the same system that captures the time entry, so a manager approving hours sees them already converted to their own zone rather than having to do the math manually before signing off. That's the kind of workflow worth comparing across tools when you're evaluating plans and pricing, since some tools charge extra for multi-zone approval routing as an add-on rather than including it.
Daylight Saving Time Will Break Something If You Let It
Twice a year, roughly half the world's clocks shift by an hour, and the other half doesn't move at all. A firm with people in Arizona (no DST) and California (observes DST) has a one-hour gap between those two locations for part of the year and none for the rest. Multiply that across ten or fifteen zones and the "spring forward, fall back" weekend becomes a genuine risk to payroll accuracy, not a minor annoyance.
The specific failure to watch for is a timesheet approved before a DST transition getting recalculated incorrectly after it, because the system quietly recomputed duration using new local offsets instead of the original stored UTC values. If your platform stores UTC timestamps and calculates duration from those, DST transitions are a non-event: the math never touches wall-clock time in the first place. If it stores local time and duration together, expect an hour to occasionally appear or vanish from a shift that spans a transition weekend. This is a good gut check to run on your current tool twice a year rather than finding out about it from a confused payroll run.
See how Autovella handles multi-zone time tracking in practice
Get a live walkthrough of UTC-based timestamps, per-zone approval routing, and invoicing that converts cleanly to each client's local time.
Frequently asked
Bill in the client's local time zone, since that is the invoice they are reconciling against their own calendar and their own approvals. Store the underlying timestamp in UTC so the record never changes, then display it in the client's zone on the invoice and in the contractor's zone on their timesheet. The stored fact stays fixed; only the display shifts.
Never store hours worked as a local wall-clock duration alone. Store the UTC start and end timestamp for every entry, and calculate the duration from that, not from subtracting two local clock times. That way a DST transition happening between two shifts doesn't quietly add or remove an hour from a timesheet that was already approved before the clocks changed.
Let them log time in their own local time zone, since that's the only version of the clock they will get right without thinking about it. The system should convert everything to a single stored time zone (UTC) behind the scenes for reporting, payroll, and invoicing, so approvers and finance always see consistent totals regardless of which zone each entry was logged in.