Timezone bugs are some of the hardest calendar issues to debug because nothing looks broken. The ICS file parses. The event appears. The times look correct in your code. And yet users report that the meeting is an hour early, an hour late, or drifting after updates.

Google Calendar is often blamed for this behaviour, but the reality is more subtle. Google is doing exactly what it is designed to do when it encounters ambiguous or incomplete timezone data. The problem is that ICS gives vendors far too much room to interpret time differently.

This article explains why Google Calendar shifts event times, how timezone normalisation really works, and what you must do to prevent silent time drift.

ICS does not have a canonical timezone authority

ICS supports timezones, but it does not define a single authoritative timezone database. Instead, it allows clients to interpret TZID values using their own internal rules.

This means:

• Google uses an IANA based timezone database
• Outlook uses Windows timezone mappings
• Apple uses ICU timezone rules

When you send an event with a TZID, you are assuming the receiving client understands it the same way you do. That assumption is often wrong.

If Google does not recognise or trust the timezone definition you provide, it will normalise the event into UTC internally.

Once that happens, future updates behave differently than you expect.

Why Google converts events to UTC

Google Calendar prioritises consistency over fidelity. If it cannot reliably interpret a timezone, it chooses a safe internal representation.

This usually happens when:

• the TZID is custom or non standard
• the VTIMEZONE block is missing
• the VTIMEZONE block is malformed
• daylight saving rules do not match Google’s database
• the event was imported during a DST boundary

When this occurs, Google converts DTSTART and DTEND into UTC and stores the event that way. The UI may still display the event in the user’s local time, but internally the event is now anchored to UTC.

That internal conversion is what causes later updates to appear ignored or misaligned.

The most common timezone mistake developers make

The most common mistake is assuming that including a TZID is enough.

Example:

DTSTART;TZID=Europe/London:20250328T100000

If Google does not trust the accompanying VTIMEZONE block, it ignores the TZID and resolves the time itself.

Later, when you send an update using the same local time, Google compares it to the stored UTC value and decides nothing has changed.

From your perspective, the update should apply. From Google’s perspective, the event already matches.

Why timezone bugs often appear only after updates

Many teams report that initial event creation looks correct, but updates break the time.

This happens because:

• the first import resolves the timezone
• Google stores the canonical UTC time
• your next update uses local time again
• Google compares local time to stored UTC
• Google decides the event is unchanged

This creates the illusion that Google ignored your update, when in reality your update did not differ from Google’s canonical representation.

Daylight saving time makes everything worse

DST boundaries are where most timezone bugs surface.

Common failure patterns include:

• events created before DST but updated after
• recurring events crossing DST boundaries
• updates generated in UTC but displayed in local time
• mismatched DST rules between VTIMEZONE and Google’s database

Google trusts its own DST logic more than the ICS file. If your VTIMEZONE rules disagree with Google’s, Google wins.

This is why events appear to shift by exactly one hour.

Why Outlook and Apple behave differently from Google

Outlook tends to respect VTIMEZONE blocks more strictly. If the block is present and valid, Outlook uses it. If not, Outlook may reject the event or display a warning.

Apple Calendar often trusts the system timezone and applies fewer corrections, which can result in different visible times across devices.

Google’s approach is more aggressive. It normalises first and asks questions never.

This is why timezone bugs often appear Google specific, even though the root cause is ICS ambiguity.

A broken timezone example that causes drift

BEGIN:VEVENT
DTSTART;TZID=Europe/London:20250328T100000
DTEND;TZID=Europe/London:20250328T110000
END:VEVENT

Without a matching, valid VTIMEZONE block, Google resolves this using its own rules. If those rules differ from yours, the stored event diverges immediately.

A safer way to represent time for Google Calendar

The most reliable approach when targeting Google is to remove ambiguity.

You can do this by:

• ensuring VTIMEZONE blocks exactly match IANA definitions
• keeping DTSTART and DTEND consistent with those rules
• avoiding custom TZIDs entirely
• or sending absolute UTC times

UTC based events are boring, but they are predictable.

DTSTART:20250328T090000Z
DTEND:20250328T100000Z

This removes Google’s need to interpret timezone rules at all.

Why recurring events amplify timezone problems

Recurring events combine timezone logic with RRULE evaluation. Google may:

• expand the series using its own DST rules
• split the series at DST boundaries
• store different instances with different offsets

When you later update the series, your local time representation no longer matches Google’s internal expansion.

This is why recurring meetings are the most common source of timezone complaints.

How to prevent timezone issues in real systems

Treat timezone resolution as vendor specific

Do not assume one representation works everywhere.

Never mix local time and UTC across updates

Choose one representation and stick to it.

Store canonical event times server side

Do not regenerate times from user input without reconciling DST.

Avoid rebuilding ICS files from scratch

Small formatting differences can cause Google to reinterpret the event.

How Synara handles timezone consistency

Synara resolves timezone ambiguity before the ICS file is ever generated. When you send an event through Synara, it:

• normalises time into a canonical internal format
• applies vendor specific timezone rules
• generates ICS files Google will not reinterpret
• ensures updates compare correctly to stored events
• prevents DST drift across updates and recurrences

This avoids the class of bugs where Google silently shifts times or ignores updates because of timezone normalisation.

Summary

Google Calendar shifts event times when:

• the TZID is ambiguous or untrusted
• VTIMEZONE blocks are missing or invalid
• DST rules differ from Google’s database
• updates reuse local time after UTC normalisation
• recurring events cross DST boundaries

Timezone bugs are not random. They are the result of ICS giving clients too much freedom.

Once you understand how Google resolves time internally, these failures become predictable and avoidable.

If you want predictable time handling across all calendar clients

Synara gives you deterministic calendar behaviour across Google, Outlook and Apple without maintaining timezone logic yourself. You send a clean JSCalendar object and Synara handles timezone resolution, DST rules, vendor specific formatting, update propagation and recurring event consistency.

If you are tired of chasing one hour offsets and invisible update failures, Synara ensures every attendee sees the same time on every calendar.

Learn more → synara.events
API docs → synara.events/docs