Why is TZID=EST invalid in an .ics file?

Calendar files should use clear time zone identifiers. Abbreviations like EST, CST, and PST are ambiguous and often fail across calendar apps.

Do I need a VTIMEZONE block?

When an ICS file uses a TZID on date-time properties, it should provide the corresponding VTIMEZONE definition so the file carries the rules for that identifier.

What is the safest way to avoid timezone issues?

Validate the file, repair invalid time zone references, and test the repaired file in the calendar app that failed.

TZID and VTIMEZONE errors in ICS files

This is the technical reference for how an .ics file represents event times. If you only need to troubleshoot an event that moved or appears one hour off, start with the plain-language wrong-time guide.

The core question is whether each date-time value is UTC, floating local time, or local time tied to a named zone—and whether that choice remains consistent across the event and any recurrence exceptions.

For a quick repair path:

Fix calendar import errors

The three common ways to represent an event time

UTC time

DTSTART:20250310T140000Z
DTEND:20250310T150000Z

The trailing Z means UTC. The calendar app converts that instant into the viewer’s local zone. Do not attach a TZID parameter to a UTC value.

TZID-qualified local time

DTSTART;TZID=America/New_York:20250310T100000
DTEND;TZID=America/New_York:20250310T110000

Here, TZID=America/New_York says that 10:00 and 11:00 are local wall-clock times in that named zone. The same identifier should be represented by an appropriate VTIMEZONE component in the calendar file.

Floating local time

DTSTART:20250310T100000
DTEND:20250310T110000

With no trailing Z and no TZID, the value is floating. It is 10:00 wherever the calendar interprets it, rather than one globally fixed instant. Floating time can be intentional, but it is a common cause of surprises when the event was meant for a specific location.

How TZID and VTIMEZONE fit together

TZID is the identifier used by properties such as DTSTART, DTEND, and RECURRENCE-ID. VTIMEZONE is the calendar component that supplies the relevant time zone definition and daylight-saving transitions.

A portable file using TZID=America/New_York should pair that reference with a matching definition:

BEGIN:VTIMEZONE
TZID:America/New_York
...
END:VTIMEZONE

BEGIN:VEVENT
DTSTART;TZID=America/New_York:20250310T100000
DTEND;TZID=America/New_York:20250310T110000
...
END:VEVENT

The TZID strings must match. A reference to America/New_York does not match a definition labeled US/Eastern, even if a particular time zone database treats them as related. A TZID reference without an appropriate VTIMEZONE definition leaves the destination to reject the file or supply its own interpretation.

DTSTART, DTEND, and recurrence consistency

The start and end of an event should use compatible time semantics. Common errors include:

a UTC DTSTART paired with a local DTEND
a named-zone DTSTART paired with a floating DTEND
a DTEND that uses a different TZID unintentionally
a recurring event whose exception uses a different value type or time zone from the original DTSTART

For recurring events, keep RECURRENCE-ID consistent with the original DTSTART. Otherwise an exception may fail to replace the intended occurrence or may appear at a shifted time. Test series across daylight-saving boundaries, because a fixed UTC offset is not a substitute for a zone’s transition rules.

Technical troubleshooting checklist

Determine whether each date-time is UTC, floating, or TZID-qualified.
Replace ambiguous abbreviations such as EST or PST with the intended unambiguous identifier.
Confirm every referenced TZID has the appropriate matching VTIMEZONE definition.
Keep DTSTART, DTEND, and RECURRENCE-ID value types and time zone usage consistent.
Validate the file, then test it in the calendar application that originally exposed the problem.

Hand-editing one label is often insufficient. The definition, recurrence exceptions, and other date-time properties may need to change together.

Safe repair path

Validate the .ics file.
Identify whether the issue is a time zone label, missing time zone context, recurrence drift, or a broader formatting problem.
Generate a repaired file instead of repeatedly importing the broken one.
Test the repaired file in the calendar app that originally failed.

CorrectICS can identify these blockers and generate an import-ready file when safe fixes are available.

Validate iCalendar file

If the structure looks correct but the imported event still moves, return to the wrong-time symptom guide for migration and destination troubleshooting.

Developer docs

Detailed time zone generation notes, examples, and API validation guidance are kept in authenticated Developer documentation:

Open Developer docs

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.

Try the CorrectICS Autofix Tool Back to Help