How to Validate an ICS Calendar Feed and Fix Common Errors

Check the text, the time zone, and the event timeline.

An ICS file is a plain text calendar format used to share events. You may see it when you subscribe to a school calendar, add a holiday list, or share rental availability. The file may be small, but dates and time zones make it easy to read the wrong event time.

An ICS calendar feed validator can help you find missing fields, unreadable dates, repeated event IDs, and time-zone warnings. This guide explains what to inspect and how to fix the source. It also covers a common question: why can a file look valid while two calendars still show different results?

What is inside an ICS file?

ICS uses the iCalendar format described by RFC 5545. A calendar file usually starts with a calendar wrapper and contains one or more event blocks. An event can have a unique ID, start and end dates, a summary, and other details.

BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
UID:example-event-001
DTSTART:20261030T150000Z
DTEND:20261030T160000Z
SUMMARY:Planning meeting
END:VEVENT
END:VCALENDAR

This small example uses a time in UTC, marked by the letter Z. Many calendars use local time with a time-zone identifier instead. A repeating event may also include a recurrence rule. Those details matter when a calendar app turns the text into dates and times.

Use the CalendarCheck workflow page to see what this checker inspects. The current product parses calendar content and shows an event timeline. It does not contact a rental marketplace or prove that a third-party platform refreshed the feed.

Check that the calendar can be read

Start by checking the file wrapper. A calendar should open and close its main block. Each event block should also start and end. A missing line break, broken quote, or cut-off upload can make a parser stop before it reaches every event.

Look for required event details. An event without a usable start time cannot be placed on a timeline. A missing end or duration may cause an application to guess or reject the event, depending on the context. Some fields are optional. Check the standard and the receiving calendar’s rules instead of assuming that every event needs the same fields.

If the calendar URL returns a sign-in page, an error page, or an HTML page instead of calendar text, the link may not be a public feed. Do not try to bypass a password or permission check. Ask the calendar owner for the correct public subscription link or export file.

Review the start and end dates

Read one event at a time. Confirm its start and end, then compare the result with the owner’s calendar. Check whether the event is all day or has a time. An all-day event may use a date without an hour. A timed event needs a clear time interpretation.

Make sure the end comes after the start. Check for a date in the wrong year, a month and day that were reversed, or a meeting placed just after midnight because its time zone was read as UTC. If the file has many events, inspect the first and last event as well as a few from different months.

Use a calendar app or the ICS example page to compare a sample timeline. A preview can reveal an obvious one-hour shift or an event that lands on the wrong day. Always keep the original feed if you make a change.

Check all-day events and end dates

An all-day event often uses a date value without a clock time. In iCalendar, an end date can be exclusive. That means an event for October 30 may start on October 30 and end on October 31 to cover that one full day. If a file uses October 30 for both start and end, the event may have no span or may display in an unexpected way.

Do not change an end date just because it looks one day later. Check the event’s intended span and the format rule. A hotel stay, for example, may use an arrival date and a checkout date. The checkout date is not another occupied night. The source system and target calendar may display this differently, so compare a known reservation in both places.

For timed events, check whether the end time is earlier only because the event crosses midnight or spans several days. Compare the full date and time, not just the hour. An overnight event needs an end date on the next day.

Understand time zones and daylight saving time

A time such as 9:00 AM is not complete by itself when people live in different time zones. It needs a zone or an offset so a calendar knows which moment the event means. A feed may use UTC with Z, local time with a TZID, or a time-zone component that describes local rules.

Daylight saving time can change the offset during the year. NIST notes that U.S. daylight saving time begins and ends at different local dates each year under current law. A recurring event set for 9:00 AM local time should normally remain at 9:00 AM local time after a seasonal clock change. If it shifts by one hour, check whether the file describes a wall-clock time or a fixed UTC time.

RFC 5545 explains how a time zone is used for recurring events, including local times that repeat or do not exist during a clock change. A calendar checker can report missing or unclear zone data, but it cannot decide what the event owner intended. Ask whether the event should follow local clock time or stay at the same exact UTC time.

Common time values in an ICS feed
Value style	Example	What to confirm
UTC	20261030T150000Z	Is 15:00 UTC the intended moment?
Local with zone	TZID=America/New_York:20261030T110000	Does the named zone match the event?
Date only	20261030	Is this meant to be an all-day event?
Floating local time	20261030T110000	Does the receiver know which local zone applies?

Do not “fix” a time by adding or subtracting an hour until you know the intended zone. A manual one-hour correction can be right in one month and wrong after a time change.

Check event IDs and repeated bookings

An event UID is a stable identity for the event. A calendar app may use it to recognize an update to an event it already has. If every export creates a new UID, importing the feed again can add another copy rather than update the old one.

Look for blank or repeated UIDs inside the same feed. If you see the same title and date twice, confirm whether the owner created two separate events or exported one event twice. A duplicate can also come from importing a calendar more than once into a destination that does not replace previous entries.

When repairing a feed, do not change every UID just to make the file unique. A new UID can make a receiving calendar think every event is new. Keep the identifier stable when updating the same event, and use the calendar system’s export method when possible.

Review recurrence rules and exceptions

A repeating event can use a recurrence rule such as every week or every month. It may also include dates to add or exceptions to skip. A short preview may show only the next months even when the rule continues farther into the future.

Check the rule’s start date, end date, count, and time zone. Ask whether a holiday or one-time change should be included. Look for an exception that removes the wrong occurrence or an end date that stops the series too soon.

Recurrence can be complex. If a calendar is important, check several future dates in the receiving app, including one near a daylight saving change and one near an exception. A valid recurrence line does not prove that every destination app displays it the same way.

Fix the feed at its source

If the file comes from a booking system, calendar platform, or website plugin, repair the settings that create the feed when possible. Hand-editing a downloaded file may help you understand the issue, but the next export can bring the error back.

After a source change, download a new copy and check it again. Compare the event count and a few known dates with the source calendar. If the calendar is a rental availability feed, check that reservations and blocked days appear correctly before you rely on it.

Keep feed links private when they contain a token. A private ICS URL can act like a password. Do not post it in a public ticket or message. If you think the link was shared too widely, ask the calendar owner whether it can be replaced. CalendarCheck says to test only a feed you own or are authorized to use.

Why a valid ICS file may not sync

A checker reads the file you submit. It does not know when a third-party calendar last fetched the URL, whether a cache is stale, or whether the destination service accepts the feed. A correct file can still be delayed by polling, a network error, a permission change, or a platform rule.

Check the feed URL in the destination’s own subscription settings. Confirm it is the current link, still public to that service, and available over HTTPS if required. Then check the last refresh time and any error message shown by that platform.

Do not assume that a one-time import will keep updating. Some calendar apps copy events once; others subscribe and refresh on a schedule. Read the destination’s instructions. A file validator cannot force the destination to fetch a calendar faster.

Common ICS errors and next steps

Events appear one hour early: check UTC, TZID, and daylight saving rules. An event is on the wrong day: review date-only versus timed values. Duplicate entries appear: inspect UIDs and the destination’s import mode. The link shows an error page: ask for the right public feed and do not bypass access controls. Repeating events stop early: review the recurrence end date and exceptions. The file is unreadable: check the wrapper, line endings, and whether the downloaded content is really ICS.

Check your product’s calendar checking FAQ for current limits. Save the result with a note about the source and time you checked it. That makes it easier to tell whether a later change came from the feed, the destination app, or the calendar owner.

Questions about calendar feed checks

What does ICS stand for?

ICS is a common file extension for iCalendar data. The content follows a text format for events and calendar information.

Can I check a private feed link?

Only if you own it or have permission. Feed URLs can contain private tokens. Keep them out of public messages and use the approved checker or source system.

Does a valid ICS file prevent double bookings?

No. A valid file can still be fetched late or interpreted differently by another platform. Check the destination service’s refresh time and review important availability manually.

Should recurring events use UTC?

It depends on what the event means. A fixed global moment may use UTC. A local weekly meeting often needs to stay at the same local clock time. Follow the source calendar’s intended behavior.