ICS event on the wrong day or time

Floating times: read in the viewer’s zone

A floating time has no Z and no TZID. RFC 5545 says such values “are not bound to any time zone in particular”: 19:30 means 19:30 wherever the reader is. For a local venue that is often fine, but anyone whose device or calendar is set to another zone sees the event at the same clock time in their zone, which is a different moment.

The checker reads floating times in your device’s zone and says so. For the floating.ics fixture:

Next known event   Tue 10 Mar, 19:00
1 event had no time zone (“floating” times) and was read as Europe/London time.

Fix: have the exporting system write a zone. In WordPress, that usually means setting the site’s time zone properly (next step).

A fixed offset: an hour out after the clocks change

If times are correct in winter and an hour out in summer, or the reverse, look for a fixed UTC offset. The Events Calendar’s documentation is direct about this: “UTC offsets do not accommodate daylight saving time”, and you “must use a location-based timezone”.

In WordPress, check Settings → General → Timezone. It should be a city, such as London, not UTC+0. A site set to UTC+0 treats a 19:00 event in July as 19:00 UTC, which is 20:00 in the UK.

Then check Events → Settings → Display → Date & Time in The Events Calendar. It chooses between the site-wide zone and each event’s own zone. The documentation notes that in site-wide mode, changing an individual event’s zone makes no difference on the front end.

A zone name the reader doesn’t recognise

RFC 5545 says a VTIMEZONE definition “MUST be specified for each unique TZID”. In practice many feeds skip it and use a standard IANA name such as Europe/London or America/New_York, which most apps, and the checker, can still resolve. Other systems write their own names, such as Windows’ GMT Standard Time, which only work if the definition is in the file.

The vtimezone.ics fixture uses the Windows name with its definition, either side of the UK clock change on 29 March 2026. The checker converts both correctly:

Tue 10 Mar, 19:00   Before the clocks change (GMT)
Tue 31 Mar, 19:00   After the clocks change (BST)

When a name can’t be resolved at all, the true time could be anywhere from 14 hours earlier to 12 hours later than written, so the date itself is uncertain. The checker shows the time as written and marks the count Incomplete only if that uncertainty could move an event in or out of the 30-day window:

Incomplete count
At least 1 event is upcoming in the next 30 days. The real number may be higher.
1 event uses a time zone that couldn’t be identified. Its date could fall either side of the window.

Fix: have the exporter include VTIMEZONE definitions, or use IANA zone names. Check which zone was meant with whoever manages the source calendar.

All-day events that move a day

An all-day event should be a date (VALUE=DATE), which has no time to convert. Trouble starts when an exporter writes an all-day event as midnight UTC instead. Midnight UTC on Saturday is still Friday evening anywhere west of UTC, so the event appears on Friday there. In the file, look for T000000Z on events that are meant to last all day.

Fix: export all-day events as dates. If the exporter can’t, set its time zone to the audience’s zone so midnight is local midnight.

Compare the instant, not the clock

When the website and a calendar app disagree, convert both to UTC before deciding who is wrong. Take the DTSTART from the file, work out the UTC instant (the checker’s event list shows times in the zone it states), and compare it with what the website shows for its own zone. If the instants match, only the display zone differs. If they don’t, the data is wrong at the source.