Outlook missing VTIMEZONE in ICS: how to fix it
If an .ics file:
- imports in Apple Calendar but fails in Outlook,
- imports in Google Calendar but shifts times in Outlook, or
- throws a “missing VTIMEZONE” style error,
the root cause is often: your events use TZID=... local times, but the file doesn’t include a matching VTIMEZONE definition.
Fastest path:
- Validate the file with the free ICS validator.
- Upload to /fix to generate a repaired
.icswhen fixes are available.
What VTIMEZONE does (and why Outlook is picky)
In a timezone-based timestamp like:
DTSTART;TZID=America/New_York:20250310T090000
the TZID points to a timezone definition that should exist in the same file:
BEGIN:VTIMEZONE
TZID:America/New_York
...
END:VTIMEZONE
Some clients will “guess” timezone rules if VTIMEZONE is missing; Outlook/Exchange often won’t (or guesses differently), causing failures or shifts around DST.
Common fixes
1) Replace invalid TZIDs first
If you see TZID=EST / TZID=PST, fix that first:
2) Add/repair the matching VTIMEZONE
If you use local times with TZID, make sure:
- each TZID referenced by
DTSTART/DTENDexists asTZID:inside aVTIMEZONEblock - the TZID strings match exactly (case/spacing matters)
3) Consider UTC when appropriate
If you don’t need “floating local time” behavior, using UTC (Z) can reduce client-specific timezone differences. But this is only safe if you’ve converted the time correctly.
If your symptom is “events at the wrong time”
Start here for the user-facing workflow:
And for the deeper technical breakdown:
Fix your .ics file in seconds
Upload an iCalendar file and get a clean, import-ready version for Google Calendar, Outlook, Apple Calendar, and Teams.