Remote team time tracking across timezones works best when you capture activity at the source — git commits, pull requests, and calendar events — in each developer’s local timezone, normalise everything to UTC for reporting, and let managers view data in whichever timezone their audience needs.
Your frontend developer is in Lisbon, your backend engineer is in Singapore, and your DevOps lead is in Chicago. It’s always working hours somewhere — but whose working hours count for billing, and how do you generate a coherent time report? Manual timers were designed for co-located teams. They break down the moment your team spans more than two timezones. The solution isn’t stricter policies about when to start and stop timers. It’s a fundamentally different approach: track the work itself, not the presence of the person doing it.
Why Timezone Differences Break Traditional Time Tracking
Manual time tracking assumes synchronous work. A developer starts a timer, works for two hours, stops the timer. That model collapses across timezone spreads of 8 hours or more.
Reporting periods become ambiguous. When a developer in UTC+8 pushes code on Monday morning, it’s still Sunday evening in UTC-5. If your sprint runs Monday to Friday, that work either falls outside the reporting window or requires manual adjustment.
“End of day” deadlines are meaningless. A timesheet deadline of “Friday 5pm” means different things to 12 different people on 12 different clocks. Some developers submit 16 hours before the deadline. Others miss it entirely because they interpreted it as their local Friday.
Client billing timezone creates confusion. You invoice the client in US Eastern. Half your team works in European timezones. A session that starts at 10pm CET on Thursday appears on the US timesheet as a Friday session. If it’s a weekly invoice, which week does it belong to?
Daylight saving shifts compound the problem. European clocks change one week before US clocks. For two weeks every spring and autumn, your team’s UTC offsets shift by different amounts at different times. Automated tools that don’t handle DST correctly produce two weeks of misaligned data — twice a year.
The fundamental issue is that manual timers treat a working day as a bounded unit with a clear start and end. For distributed teams, work flows around the clock in overlapping segments. No timer-based system handles that gracefully.
Common Timezone Time Tracking Mistakes to Avoid
Even teams that acknowledge the timezone problem often address it with policies that create new problems.
Requiring all time in a single timezone forces developers to do timezone arithmetic before every entry. Errors accumulate. A developer in Auckland who forgets to subtract 13 hours quietly corrupts two weeks of data before anyone notices.
Applying co-located working hour policies to distributed teams treats flexibility as a compliance problem. Requiring developers to “be online” during a fixed window ignores that async teams often produce their best work outside that window.
Scheduling mandatory standups across 16 timezones forces someone onto an early morning or late night call every single day. Beyond the morale impact, it creates attendance gaps that make time data unreliable — people log off to sleep and miss the window when their time is supposed to be recorded.
Treating all hours as equal misses the distinction between overlap hours — when two or more team members are available simultaneously — and solo async work. Overlap hours are a finite, valuable resource. Knowing how they’re consumed is essential for capacity planning.
How to Set Up Timezone-Aware Time Tracking
Setting up distributed team time tracking correctly requires decisions at every layer of the stack.
Step 1: Capture in local timezone, store in UTC. Every time entry should be recorded in the developer’s local timezone — that’s what maps to their memory of when they did the work. Your database stores everything in UTC. Your reporting layer converts UTC to whatever timezone the report viewer needs.
Step 2: Use git-based tracking as your primary source. Git commits carry UTC timestamps automatically. A developer who pushes at 9am JST on Tuesday has committed code with a UTC timestamp of Monday 00:00. No manual input required, no timezone math needed, no DST errors possible. The commit record is the time record.
Step 3: Integrate calendar data with timezone awareness. Calendar events already carry timezone information. A Google Meet scheduled for “10am CET” knows that’s “09:00 UTC” in winter and “08:00 UTC” in summer. Pull calendar data into your time tracking system and the DST correction is already handled.
Step 4: Define reporting periods in UTC. A week runs Sunday 00:00 UTC to Saturday 23:59 UTC. A month starts on the first at 00:00 UTC. When everyone’s data is normalised to UTC, these boundaries are unambiguous. Developers in UTC+13 will see Monday as their last day of the reporting week. That’s correct — their Monday falls within the UTC Saturday window.
Step 5: Allow flexible submission windows. Instead of “submit timesheets by Friday 5pm EST”, use “within 24 hours of your local work week end”. A developer whose Friday ends at 6pm AEST has until Saturday 6pm AEST to submit. This eliminates timezone-driven missed deadlines without relaxing the policy.
Step 6: Build timezone-aware dashboards. Managers should be able to view team data in their own timezone. A CTO reviewing team time utilisation in New York should see Singapore developers’ hours mapped to ET business days, not raw UTC timestamps. Most time tracking platforms support this with a single configuration setting — if yours doesn’t, it’s a product limitation worth addressing.
Async Work Patterns and Time Attribution
Distributed teams do most of their work asynchronously. Time tracking for async-first teams needs to reflect how work actually flows, not how it would flow if everyone were in the same office.
Async code reviews create a split between when a PR is submitted and when it’s reviewed. Both halves of that interaction are billable work. The developer who submitted the PR worked from 9-11am JST. The reviewer who picked it up worked from 2-4pm CET. Both sessions should appear in the project’s time log, attributed to the respective developer.
Handoff patterns are common on distributed teams: developer A works on a feature during their morning, commits progress, and developer B picks it up 8 hours later during their morning. This is a feature, not a bug. The work is continuous even though no single developer works continuously. Time tracking should capture both sessions and associate them with the same task.
Slack messages and async communication have time costs that are easy to miss. A developer who spends 45 minutes responding to async threads during their working session did 45 minutes of work. If that communication is in service of a client project, it’s billable. Tools that only track coding activity miss this entirely.
Documentation and design work happen in the gaps between coding sessions. A developer who writes a technical spec during their overlap window, then pushes the code during their solo hours, has done work in both sessions. Capturing only the code push underestimates actual project time.
The key principle: track activity, not presence. It doesn’t matter when work happens — it matters that it’s captured. An async-first team doesn’t have a nine-to-five. They have a series of work sessions that happen in different timezone windows. Each session needs a time record.
Managing Remote Team Utilisation Across Timezones
Utilisation calculations for distributed teams require adjustments that don’t apply to co-located teams.
Normalise for local working day length. A developer in a country with shorter statutory working days produces different utilisation numbers than one in a country with longer expected hours. If you’re calculating utilisation as “hours worked / hours available”, you need the denominator to reflect each developer’s actual working capacity, not a universal standard.
Account for public holiday differences. Your US-based team has Thanksgiving off. Your UK-based team doesn’t. Your India-based team has Diwali off. Your EU team has varying country-specific public holidays. A utilisation dashboard that doesn’t account for these will show artificially low numbers for team members on holiday and flag them incorrectly as underperforming.
Track overlap utilisation separately. Overlap hours — the window when two or more team members are simultaneously available — are the scarcest resource for a distributed team. If you have a four-hour overlap window between your US East and Western Europe staff, and regular meetings consume three of those hours, you’ve consumed 75% of your synchronous collaboration capacity before any unplanned communication happens. That’s worth measuring.
Build team-level views, not individual surveillance. A useful utilisation dashboard shows how the team’s capacity is allocated across projects and clients. It doesn’t show how many hours each individual worked on Tuesday. The first informs planning decisions. The second damages trust without producing actionable data. For engineering managers, this distinction matters as much as the data itself.
Key Takeaway
Remote team time tracking across timezones works when you track activity at the source (git commits, calendar events), capture timestamps in local time, normalise to UTC for storage, and report in the timezone your audience needs. Async-first teams should track work outputs, not presence windows.
Frequently Asked Questions
What’s the best way to track time for a team spread across multiple timezones?
Use activity-based tracking that captures work at the source — git commits, pull requests, and calendar events — rather than requiring manual timer input. Store all data in UTC and let your reporting layer present it in each viewer’s preferred timezone. This eliminates the need for developers to do timezone arithmetic and removes the DST error risk that plagues manual systems.
Should remote teams report hours in their local timezone or the company’s timezone?
Developers should record time in their local timezone — that’s what maps to their memory of when they worked. The company should store and report in UTC, with views configurable per manager. Forcing everyone to report in a single company timezone creates conversion errors and misattributes work sessions to the wrong reporting period.
How do you handle time tracking when developers work flexible hours across timezones?
Define reporting periods in UTC rather than local business day boundaries, and use flexible submission windows (“within 24 hours of your local week end”) instead of fixed-timezone deadlines. Systems that track work automatically from git and calendar activity don’t require developers to actively log sessions, which makes flexible hours completely compatible with accurate reporting.
Does time tracking work for async-first remote teams?
Yes, but only if the tool tracks activity rather than presence. Async teams don’t have a synchronised working day, so timer-based tools that require active start/stop don’t fit the workflow. Activity-based tracking from git, code review platforms, and calendar integrations captures async work naturally without requiring any timer discipline. Both the developer who submitted the PR and the reviewer who approved it 8 hours later get accurate time records.
How do you calculate utilisation for remote teams in different timezones?
Normalise each developer’s available hours against their local working day length and local public holidays before calculating utilisation. Track overlap utilisation — the fraction of your synchronous collaboration window consumed by meetings — as a separate metric from total utilisation. Build team-level dashboards that aggregate capacity by project, not individual surveillance views by developer.
Ready to Track Your Distributed Team’s Time Automatically?
Keito tracks developer time from git — timezone-aware by default. No timers, no timezone math, no DST surprises. Every commit, PR, and code review is captured with accurate UTC timestamps that map cleanly to any reporting timezone.