How to Track Time Across Timezones Without Losing Your Mind

You have a developer in Lisbon who clocks out at 6 PM local time. A designer in Chicago who starts at 9 AM Central. A project manager in Singapore who overlaps with both for exactly two hours. They’re all billing to the same client. The client is in London.

Now generate the invoice.

If your time tracking tool stores everything in one timezone — or worse, in whatever timezone the person happened to be in when they logged — you’re going to spend Friday afternoon reconciling instead of billing. We know because we did this for two years before building Miru.

---

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.