My imported events are all off by one or two hours. What happened?

A constant shift across every event is the signature of a zone that was dropped and replaced. Open the original .ics in the viewer: if the start times look right there, the file kept its zone and the application you imported into is applying a different one — check its calendar time-zone setting, which is separate from the operating system's. A shift that varies event by event is a different problem, usually a mix of Z and floating times in one file.

Which form should I use when I publish a calendar?

Z for anything with a fixed instant — a webinar, a match, a deadline — because it cannot be misread and needs no zone database at the other end. TZID for a calendar people live by locally, such as a school timetable or an office's opening hours, where the wall-clock time is the thing that must stay put across a daylight-saving change. VALUE=DATE for whole days. Floating times only when you genuinely mean local time everywhere, which in practice is New Year and very little else.

Does the viewer change my file?

No. It reads the file in your browser and shows what is in it; the file on disk is untouched, and nothing is sent anywhere. That is the point of looking before converting — you can settle an argument about a start time without committing to anything.

The Same .ics File Can Mean Five Different Times

Published 9/7/2026 · 4 min read · File tools

Daniel Okonkwo — Front-end developer and tech writer at OneKitly

Web performance · File formats

Checked against 3 sources

View profile →

In short

A DTSTART line comes in three shapes. DTSTART:20260908T080000Z ends in Z and is an instant in UTC — the same moment for everyone, and the only form nothing can misread. DTSTART;TZID=Europe/Paris:20260907T140000 is a wall-clock time plus the name of the zone it belongs to, which is correct only if whatever reads it knows that zone. DTSTART:20260907T140000, with neither Z nor TZID, is a floating time: two o'clock wherever you happen to be, which is what you want for a New Year countdown and almost never for a meeting. The dangerous case is the middle one handled carelessly: strip the TZID, keep the digits, and the wall-clock time gets re-anchored to whichever machine is doing the reading. The viewer here shows you which of the three you are looking at before anything is converted, and the converters carry the zone through untouched rather than guessing.

iCalendar writes a start time in one of three ways, and only one of them is unambiguous. A meeting written with a named zone, converted on machines in Paris, New York and Honolulu, spanned nineteen hours and changed day.

Why the file names a zone instead of an offset

Writing +02:00 would fix the meeting to a number that stops being true twice a year. A weekly appointment at 14:00 in Paris is +02:00 in September and +01:00 in November, and the point of a recurring event is that it stays at two in the afternoon on both sides of the change. Naming Europe/Paris says which rulebook to apply; the offset is then looked up, date by date, in a zone database that gets updated whenever a country moves its clocks.

That is also why converting a TZID time to UTC is not a subtraction you can do in your head, and why a tool that has no zone database should not try. Keeping the name and the wall-clock digits exactly as the file wrote them is lossless; replacing them with an instant computed from the wrong zone is not, and it is the kind of error that looks fine on screen until somebody joins a call an hour late.

The all-day event, which is not a time at all

A birthday, a public holiday or a day off is written DTSTART;VALUE=DATE:20261225 — eight digits, no time, and the parameter that says so. It means the whole of 25 December wherever the reader is, which is exactly right for Christmas and would be wrong as an instant. Rewrite it as a datetime and it becomes midnight UTC, which is still the 25th in Europe and already the 24th anywhere west of Greenwich. The VALUE=DATE marker is carried through here rather than being resolved into an hour.

What to check before you trust an imported calendar

Open the file in the viewer and look at one event you know the real time of. If it is right there, the file is right and any later disagreement comes from the application you imported into. Three habits cover almost everything: prefer the Z form when you publish a calendar other people will subscribe to, keep TZID when you are moving your own calendar between applications, and never edit a start time by hand in a text editor without checking which of the three forms the line is in.

One meeting written TZID=Europe/Paris, re-anchored to the reading machine
Machine reading the file	What 14:00 becomes	Off by
Europe/Paris	20260907T120000Z	correct
UTC	20260907T140000Z	+2 h
America/New_York	20260907T180000Z	+6 h
Asia/Tokyo	20260907T050000Z	-7 h
Pacific/Honolulu	20260908T000000Z	+12 h, next day

ICS viewerOpen a calendar invitation or export and read its events before importing anything.Try the tool →

Frequently asked questions

My imported events are all off by one or two hours. What happened?: A constant shift across every event is the signature of a zone that was dropped and replaced. Open the original .ics in the viewer: if the start times look right there, the file kept its zone and the application you imported into is applying a different one — check its calendar time-zone setting, which is separate from the operating system's. A shift that varies event by event is a different problem, usually a mix of Z and floating times in one file.
Which form should I use when I publish a calendar?: Z for anything with a fixed instant — a webinar, a match, a deadline — because it cannot be misread and needs no zone database at the other end. TZID for a calendar people live by locally, such as a school timetable or an office's opening hours, where the wall-clock time is the thing that must stay put across a daylight-saving change. VALUE=DATE for whole days. Floating times only when you genuinely mean local time everywhere, which in practice is New Year and very little else.
Does the viewer change my file?: No. It reads the file in your browser and shows what is in it; the file on disk is untouched, and nothing is sent anywhere. That is the point of looking before converting — you can settle an argument about a start time without committing to anything.

Articles you may find interesting

All guides →

ExplainerA Recurring Event Is One Line in the CSV, Not TwelveAn .ics file stores a weekly meeting once, with a rule attached. Export it to CSV and you get a single row for the whole series — which is the file being honest, not the converter losing rows.How-toOpening an .eml File Without Telling the SenderA saved message is a text file you can read anywhere. The catch is that opening it in something that loads remote images announces the moment you did — which is what a tracking pixel is for.How-toSplitting a File That Is Too Big to SendThe last resort when nothing can be compressed further. It works, and it has three sharp edges: the parts are useless on their own, the order is absolute, and the megabyte you set is not the megabyte the limit means.ExplainerWhy Compressing a File Twice Does Not Halve It TwiceThe first pass takes 30% off and the second takes nothing. That is not a broken tool — it is the difference between removing redundancy and removing information, and knowing which one you are doing tells you when to stop and what a second attempt actually costs.GuidePull the Plug: Which Online File Tools Actually Upload Your DocumentEvery online file tool promises your document is safe. Almost none tell you whether it leaves your machine at all. There is a five-second test that settles it without reading a single privacy policy, and it works on any tool — including this one.ExplainerAn Attachment Grows by a Third Inside the EmailMail carries files as text, three bytes written as four characters. A 10 MiB attachment occupies 13.68 MiB of the message, which is why a 25 MB limit really means about 18 MiB of files.

Sources

Spotted a mistake in this article?