DEV Community

Michael Lip
Michael Lip

Posted on • Originally published at zovo.one

Working Across Timezones: The Mental Model That Prevents Scheduling Disasters

#webdev #beginners #programming #productivity

Remote teams span timezones. A team with members in San Francisco, London, and Tokyo has a 3-hour window where all three are in reasonable working hours. Miss this window and someone is in a meeting at midnight.

I manage collaborations across 4+ timezones regularly, and the mistakes I made early on taught me a system that works.

The overlap calculation

San Francisco (PST/PDT): UTC-8 / UTC-7
London (GMT/BST): UTC+0 / UTC+1
Tokyo (JST): UTC+9

Working hours assumption: 9 AM - 6 PM local time.

In winter (no DST adjustments):

  • SF is awake: 17:00-02:00 UTC
  • London is awake: 09:00-18:00 UTC
  • Tokyo is awake: 00:00-09:00 UTC

The three-way overlap: 00:00-02:00 UTC. That is 4-6 PM in SF, midnight-2 AM in London, 9-11 AM in Tokyo. London is asleep. No good.

The realistic approach: two overlapping pairs.

  • SF + London overlap: 17:00-18:00 UTC (9-10 AM SF, 5-6 PM London). One hour.
  • London + Tokyo overlap: 00:00-09:00 UTC... actually 09:00 UTC is when London starts and Tokyo ends. Overlap: 09:00 UTC (9 AM London, 6 PM Tokyo). Barely one hour.

This is why globally distributed teams rely heavily on asynchronous communication.

DST makes everything worse

Daylight saving time shifts do not happen on the same dates worldwide. The US shifts in March and November. The EU shifts at the end of March and October. Japan does not observe DST at all. Australia shifts in April and October (opposite hemisphere).

During the gap between US and EU DST changes, the London-to-SF offset changes from 8 hours to 7 hours for about 3 weeks. This regularly causes missed meetings when calendar software does not handle the transition correctly.

The safe practice: always specify timezone explicitly. "3 PM ET" is unambiguous (even during DST transitions, ET automatically adjusts). "3 PM EST" is technically wrong during daylight saving time (it should be EDT). "3 PM UTC-5" is always precise.

UTC as the common reference

For scheduling systems, logs, databases, and any programmatic use, store everything in UTC. Convert to local time only for display. This eliminates DST ambiguity and makes time arithmetic straightforward.

In databases: store timestamps as UTC. In APIs: return timestamps in ISO 8601 format with the Z suffix (2025-03-25T14:30:00Z). In logs: use UTC. In user interfaces: convert to the user's local timezone for display.

The Intl.DateTimeFormat API makes this straightforward in JavaScript:

const utcDate = new Date('2025-03-25T14:30:00Z');
const formatter = new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York',
  dateStyle: 'medium',
  timeStyle: 'short',
});
console.log(formatter.format(utcDate)); // Mar 25, 2025, 10:30 AM
Enter fullscreen mode Exit fullscreen mode

The IANA timezone database

Always use IANA timezone identifiers (America/New_York, Europe/London, Asia/Tokyo) rather than abbreviations (EST, GMT, JST). IANA identifiers automatically handle DST rules, historical changes, and edge cases. Abbreviations are ambiguous (CST could be Central Standard Time, China Standard Time, or Cuba Standard Time).

The tool

For seeing current times across multiple cities at a glance and finding meeting time overlaps, I built an electronic world clock that displays multiple timezone clocks simultaneously and highlights overlap windows for scheduling.

I'm Michael Lip. I build free developer tools at zovo.one. 500+ tools, all private, all free.

Top comments (0)