How to Track Time Across Timezones Without Losing Your Mind

How to Track Time Across Timezones Without Losing Your Mind is straightforward once you stop adding process theater.

Practical guide for distributed teams: UTC storage, local display, and billing across timezones without spreadsheet chaos. We write from operating experience, not trend-chasing.

The UTC Rule

Every time entry in Miru is stored in UTC. No exceptions. When a developer in Lisbon logs “2 hours on the Acme project at 3 PM,” Miru stores that as 15:00 UTC+0 (or 14:00 UTC, depending on daylight saving). The developer sees their local time. The project manager sees their local time. The invoice shows the client’s local time. But the source of truth is UTC, always.

This sounds obvious. Most tools don’t do it. They store the timestamp in the user’s local timezone, which means the same moment in time gets recorded differently depending on who logged it and where they were sitting. That breaks reports, breaks invoices, and breaks trust.

How Miru Handles It

Each user sets their timezone in their profile. Miru handles the conversion everywhere:

• Time entries display in the user’s local timezone
• Reports can be generated in any timezone — the client’s, the team’s, or UTC
• Invoices show line items in the client’s timezone, because that’s what the client expects
• The CLI detects your system timezone automatically

There’s no “timezone settings” page with fifteen dropdowns. You set it once, and every timestamp you see is correct for you. Your colleague in another timezone sees the same entries displayed in their local time. The data is identical. The presentation adapts.

Tips for Async Billing

Beyond timezone storage, distributed teams need billing practices that account for async work:

Log daily, not weekly. The biggest timezone billing errors come from batch logging. When you log Friday afternoon for the whole week, you misremember which day things happened, and the timezone math compounds the error. Log at the end of each day while the work is fresh.

Use project-level billing, not hourly. If your team spans four timezones, per-hour billing creates arguments about which hour belongs to which day. Project-based billing with time tracking for internal visibility avoids the argument entirely.

Set invoice timezone to the client’s location. When the client in London sees “March 15, 9:00 AM — 11:00 AM,” they should see London time. Not your developer’s Lisbon time. Miru lets you set this per client.

Overlap hours are gold. Track when your team overlaps. Those 2-3 hours where everyone is online are when meetings, reviews, and handoffs happen. Bill them accurately because they’re your most expensive hours.

The Bottom Line

Timezone handling isn’t a feature. It’s infrastructure. If your time tracking tool gets it wrong, every report and every invoice downstream is wrong too. Miru stores UTC, displays local, and lets you invoice in whatever timezone the client expects.

Set it up once. Stop thinking about it. Get back to work.

Hard Stop

Run this loop for two weeks without skipping cleanup. The compounding effect is real.

Start with Miru or read the docs.

Vipul A M

Co-founder at Saeloun. Building Miru. Rails contributor. Shipping from Pune, India.