Timezones and DST Pitfalls for Schedulers
Why fixed UTC offsets fail twice a year, how IANA zones work, and how to find meeting overlap across cities without spreadsheet errors.
A recurring stand-up works for months - then one Monday half the team joins an hour early. Nobody changed the calendar invite. Daylight saving time (DST) did. Schedulers who store "UTC+2" or "same clock time every week" discover the hard way that civil time is a policy, not a constant.
This guide covers how timezones really work for remote teams, the mistakes that break meeting planners, and how to check conversions and overlap with Utilitoo's browser tools before you send the invite.
Offset is not a timezone
People say "timezone" when they mean three different things:
| Concept | Example | Stable? |
|---|---|---|
| UTC offset | UTC+01:00 | Changes when DST starts or ends |
| IANA timezone | Europe/Berlin, America/New_York | Rules change with politics; libraries update |
| City label | "London time" | Ambiguous if the city has multiple zones historically |
If your app stores +2 for "Germany in summer," it will be wrong in winter. Prefer IANA names (Europe/Berlin) so DST transitions follow published rules instead of a hard-coded offset.
Why DST breaks recurring meetings
DST is not global and not synchronized:
- The United States and European Union change clocks on different weekends.
- Some regions never observe DST (much of Arizona, Hawaii, many equatorial countries).
- Governments occasionally abolish or invent DST with short notice - libraries need updates.
A meeting defined as "every Tuesday at 10:00 local for each person" is actually several different UTC instants across the year. A meeting defined as "every Tuesday at 15:00 UTC" is stable in absolute time but shifts on each person's wall clock when their zone enters or leaves DST.
Pick the model on purpose:
- Fixed UTC - good for global ops bridges and incident windows labeled in Zulu time
- Fixed local for the host - good for a company HQ that expects everyone to adapt
- Overlap of business hours - good for customer calls across regions; recompute after DST changes
Real scheduling failures
The "plus two hours" spreadsheet
Scenario: A PM maintains a sheet: SF = UTC-8, Berlin = UTC+1. In March, Berlin springs forward and California has not yet. The sheet is off by an hour for two weeks.
Fix: Stop maintaining offset columns. Convert with Timezone Converter for one-off checks, or plan with Meeting Planner using IANA zones and business-hour windows.
Interview loop across three continents
Scenario: Candidate in Tokyo, interviewer in London, hiring manager in New York. The "afternoon" slot for London is midnight for Tokyo.
Fix: Add all three zones in Meeting Planner, set realistic business hours (not 00:00-23:59), and only offer slots inside the overlap. Keep World Clock open during the loop so nobody misreads chat timestamps.
"Same time next week" after a transition weekend
Scenario: Slack says "same time next week." One city changed clocks overnight. Half the attendees update their mental offset; half do not.
Fix: Always restate the meeting in UTC and each major local time in the invite description. After DST weekends, re-run the overlap check instead of copying last week's local times.
SaaS cron labeled in local time
Scenario: A weekly report job is scheduled for "Monday 09:00" in the server's local zone. The host VM is set to a US zone; the product team thinks the schedule is "London morning."
Fix: Document the schedule in an IANA zone explicitly. When debugging missed runs, convert log epochs with Timestamp Converter or Unix Time Converter, then map to the zone you meant - not the zone the laptop happens to use.
A practical checklist before you send invites
- Name the IANA zone for each participant (city picker tools help avoid wrong offsets)
- Decide fixed-UTC vs host-local vs overlap model
- Set business hours that match real working days - not a 24-hour window that always "overlaps"
- Check DST weekends on the calendar for every region involved in the next two months
- Paste local times for each city into the invite body
- Re-validate after any government DST policy news affecting your regions
How Utilitoo tools fit
- Timezone Converter - convert a specific date and time between zones when you already have a candidate slot
- Meeting Planner - find hours when every selected zone falls inside configurable business hours
- World Clock - keep live city clocks on screen during calls and launches
- Business Hours Checker - answer "are they open now?" in the business's zone
Conversions and planning run in your browser. You are not uploading your calendar - you are checking math before Outlook or Google Calendar freezes a wrong instant.
Common mistakes
| Mistake | What goes wrong | Better habit |
|---|---|---|
Storing only UTC+N | Breaks twice a year | Store IANA zone IDs |
| Assuming US and EU change together | Two-week confusion each spring/fall | Check both calendars |
| Overlap with 24-hour "business hours" | Fake availability | Use real 9-5 (or team norms) |
| Labeling screenshots without zone | Arguments in chat | Always write 15:00 UTC or Europe/Berlin |
| Trusting phone "world clock" widgets alone | Widgets can lag policy updates | Cross-check before high-stakes launches |
Bottom line
Timezone bugs are rarely about arithmetic - they are about which rules you assumed. Use IANA zones, decide whether the meeting is fixed in UTC or fixed in someone's local civil time, and recompute overlap around DST transitions.
Utilitoo's Timezone Converter, Meeting Planner, and World Clock are built for that check: fast, private, and boring in the best way - so the invite is right the first time.
Try these tools
- Timezone Converter - Convert times between timezones.
- Meeting Planner - Find overlapping business hours across timezones.
- World Clock - View multiple city times at once.