The short answer: most remote-first companies don't formally pick one. Neither GitLab nor Automattic, both fully distributed with public handbooks, declares a single company-wide reference clock. UTC is the fairest option for hard deadlines because it favours nobody, but it's unintuitive since nobody actually lives there. HQ time is intuitive for people near the office but implicitly centres everyone else's day around it. Most companies negotiate this per team rather than mandating one answer.
It's a genuinely reasonable question to ask when a team goes distributed: what time zone do we actually run on? The honest, slightly unsatisfying answer from looking at how real remote-first companies operate is that most of them never formally answer it.
The three common options, and their tradeoffs
- UTC. Neutral and fair, since it doesn't favour any team member's local time. The tradeoff: nobody actually lives on UTC, so every single person still has to convert it, it just moves the maths rather than removing it.
- Head-office time. Intuitive for whoever's near the office, and a natural default if the company genuinely has one location most people are close to. The tradeoff: it quietly centres the whole team's day around one region, which can feel unfair as the team spreads further out.
- The founder's or majority location's time. Practical in the early days when most of the team really is clustered somewhere, but it ages badly as the team becomes more distributed and stops reflecting where people actually are.
What GitLab and Automattic actually do
Neither of these well-documented, fully distributed companies declares one official reference clock. GitLab, which has no headquarters at all, structures its scheduling around regional overlaps rather than a single anchor time. Automattic, distributed since 2005, leaves this to individual teams rather than a company-wide policy. The pattern across the most transparent remote-first companies is negotiation, not a fixed rule.
Use UTC for hard, unambiguous deadlines, releases, cutoffs, anything where fairness matters more than intuition. Let live meetings be negotiated per team based on who's actually involved. Trying to force one clock to answer both questions is usually where the friction comes from.
Practical guidance
Rather than debating a single company-wide default, it's more useful to be explicit about which of the two jobs you're solving. For deadlines, state them in UTC and let everyone convert once. For meetings, don't anchor to any one region's time at all, show every attendee their own correct local time and let the meeting itself be the shared reference point.
That's the approach Atlas takes: instead of picking a default clock for the group, it shows everyone's real local time on a map and lets you book the meeting once, correctly, in every attendee's own time zone.
When should a team revisit its default time zone habit?
The moment your first hire lands more than two or three time zones away from wherever the rest of the team informally clusters. Up to that point, an implicit default, usually the founder's city, works fine because nobody notices it. Once a genuinely distant hire joins, that implicit default quietly starts disadvantaging exactly the person you most need to onboard well.
A useful trigger to watch for: if meetings are consistently scheduled at times that are comfortable for the founder's zone and merely tolerable, or worse, for everyone else's, that's the implicit default showing up as a real cost rather than a hypothetical one. It's worth naming out loud before it hardens into an unexamined habit nobody thinks to question.
Frequently asked
Do remote companies pick one official time zone?
Should we use UTC as our default?
Should we use head-office time instead?
What's the practical recommendation?
When should a team revisit its default time zone habit?
Stop doing timezone math
Atlas finds the time everyone's awake and adds it to your calendar in one tap.
One-time purchase, yours forever.