[ Back to all articles ](https://addcal.co/blog.md) google calendar ics time zones troubleshooting ICS Timezone Wrong in Google Calendar: Why Events Shift, and the Fix ==================================================================== By Tom •September 30, 2026 You import an .ics file into Google Calendar and the event lands at the wrong time. Usually it is off by exactly your offset from UTC: a 5pm meeting shows at 10am, a 9am class shows at 2pm. Sometimes it is off by one hour, and only for part of the year. Both come from the same place: the file told Google the wall-clock time, but not which clock. This post explains how an .ics file carries time zones, the three ways it goes wrong in Google Calendar, how to tell which one you have by reading the file, and the fix for each, whether you are the one importing or the one sending. How an .ics file says what time it is ------------------------------------- The iCalendar standard ([RFC 5545, section 3.3.5](https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5)) allows exactly three forms for a date and time. Every wrong-time problem is one of these three being misread. | What the DTSTART line looks like | What it means | Where it goes wrong | | --- | --- | --- | | `DTSTART:20261105T140000Z` | UTC. The trailing Z means "this exact moment, worldwide". | Only if the sender converted to UTC incorrectly. Otherwise the safest form for a single event. | | `DTSTART;TZID=America/New_York:20261105T140000` | 2pm on the wall clock in the named zone. | When the zone name is not one Google knows, or the file does not define it. | | `DTSTART:20261105T140000` | "Floating" time. 2pm in whatever zone the reader is in. No fixed moment. | Whenever the sender and the reader are in different zones. | The middle form has one more rule. The RFC says every `TZID` a file references must be defined by a `VTIMEZONE` block in the same file, listing the zone's offsets and its daylight-saving transitions. That block is what a calendar app falls back on when it does not recognise the zone name. Leave it out and you are relying on the reader knowing the name. The three ways it breaks in Google Calendar ------------------------------------------- ### 1. A zone name Google does not recognise, and no VTIMEZONE This is the classic. The oldest Stack Overflow thread on the subject ([2014, still collecting answers](https://stackoverflow.com/questions/23963459/importing-ics-into-google-calendar-with-correct-timezone)) has a file with `DTSTART;TZID=US-Pacific:20140606T170000`. "US-Pacific" is not a real zone identifier, and there was no VTIMEZONE, so Google had nothing to resolve it with and read the time as UTC. 5pm Pacific became 10am Pacific. The same thing happened to every published Outlook calendar in July 2023. A [Microsoft Q&A thread](https://learn.microsoft.com/en-us/answers/questions/4589725/published-outlook-calendar-ics-link-shows-wrong-ti) traced it to lines like `DTSTART;TZID=W. Europe Standard Time:20230821T100000` with no VTIMEZONE in the file. "W. Europe Standard Time" is a Windows zone name. Google, and most other readers, use the IANA database, where that zone is `Europe/Berlin`. With no definition to fall back on, the time was read as UTC and Eastern-time users saw everything four hours early. Abbreviations are the third variant of the same mistake. `TZID=EST` is ambiguous (it is also Australian Eastern Standard Time) and is not an IANA identifier. ### 2. A floating time, read in a different zone A file with no Z and no TZID is floating. The RFC's own example is "busy 11am to 1pm every day, no matter which time zone I am in". That is a real use, but almost nobody exporting a webinar means it. Google has to anchor a floating time to something, and it uses the importing calendar's time zone. So a 9am event exported by an organiser in Sydney and imported by someone in London lands at 9am London, eleven hours late. The wall clock is preserved. The moment is wrong. Spreadsheet-to-ICS converters and hand-written files produce this constantly, because leaving the zone off is the easiest thing to do. ### 3. Correct zone, wrong daylight-saving rule This is the one-hour-for-part-of-the-year case. The TZID is fine, the VTIMEZONE is present, but its transition rules are wrong: a STANDARD block with no DAYLIGHT block, or transition dates copied from an old library. Google resolves a zone name it recognises with its own rules, so Google is usually the last app to show this one; Outlook and Apple Calendar trust the file's VTIMEZONE more and show it first. If Google is right and Outlook is an hour out, look here. The related trap is UTC on a recurring event. A weekly 9am meeting written as `DTSTART:20261105T140000Z` with an RRULE is 9am New York in November and 10am New York once daylight saving starts in March, because the UTC moment is fixed and the wall clock moves. For anything recurring, the RFC intends local time with a TZID. UTC is for single events. How to diagnose it: read the file --------------------------------- An .ics file is plain text. Open it in any text editor, or paste it into the [ICS viewer](https://addcal.co/tools/ics-viewer.md), which shows every event with its parsed time and zone, and find the DTSTART line. - Ends in `Z`: the sender converted to UTC. If the time is wrong, they converted it wrong, and no import setting on your side fixes it. - Has `TZID=`: check the name against the [IANA list](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). If it is a Windows name or an abbreviation, that is your problem. Then check whether a `BEGIN:VTIMEZONE` block with that TZID exists above the events. - Neither: floating. The offset you are seeing is the difference between the sender's zone and your calendar's. One more thing worth knowing if the file came from Google itself. Google's own export (the `basic.ics` feed of a calendar) writes every timed event in UTC with a Z, and states the calendar's intended zone once at the top in an `X-WR-TIMEZONE` header. Readers that ignore that header show everything in UTC. That is not a broken file; it is a reader ignoring a non-standard header, and it is why "shared Google calendar shows UTC in Outlook" is its own genre of support thread. The fix if you are importing ---------------------------- **Floating file:** before importing, set your Google Calendar time zone to the sender's zone (Settings, General, Time zone), import, then set it back. Google reads the floating times in the calendar's zone at import time, so the events land at the intended moments and stay there when you switch back. If you already imported them at the wrong times, delete those events first, then re-import. **Unknown TZID:** edit the file. Replace the zone name on every DTSTART and DTEND with the IANA name (`Eastern Standard Time` becomes `America/New_York`), save, import. For a single event, it is faster to import and drag it to the right time. **Published Outlook calendar you subscribe to:** you cannot edit a feed. Community-built proxies exist that fetch the feed and inject the missing VTIMEZONE before Google sees it. They work, but you are routing your calendar through someone else's server, so read the code first or run your own copy. The proper fix is on Microsoft's side. The fix if you are sending -------------------------- Three rules cover every case above. 1. **Use IANA zone names, and include the VTIMEZONE.** `America/New_York`, `Europe/Berlin`, `Australia/Sydney`. Never Windows names, never abbreviations. Any decent iCalendar library emits the VTIMEZONE for you; if you are writing the file by hand, copy a block from a library-generated file. 2. **Never emit floating times for a real event.** If you do not know the zone, ask for it. A time without a zone is not a time. 3. **Prefer TZID for recurring events, UTC is fine for one-offs.** A single webinar written as a UTC instant cannot be misread. A weekly meeting must be local time plus zone or it drifts across daylight saving. For reference, this is what a correctly formed timed event looks like. It is the file AddCal generates for a 2pm New York event, trimmed to the parts that matter: ``` BEGIN:VCALENDAR VERSION:2.0 PRODID:-//AddCal-1.0//EN BEGIN:VTIMEZONE TZID:America/New_York BEGIN:DAYLIGHT DTSTART:20260308T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT BEGIN:STANDARD DTSTART:20261101T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:evt_ab12cd34ef56 DTSTAMP:20260930T045811Z DTSTART;TZID=America/New_York:20261105T140000 DTEND;TZID=America/New_York:20261105T150000 SUMMARY:Product launch webinar END:VEVENT END:VCALENDAR ``` The zone is named the way Google, Apple and Outlook all understand it, the transitions are spelled out for readers that do not, and the wall-clock time is the one the organiser typed. Test the result in all three apps before you send it to a list. They do not agree with each other, and the file that is right in one can be an hour out in another. What AddCal does about it ------------------------- An [AddCal event link](https://addcal.co/solutions/add-to-calendar-links.md) writes the file above for every event: IANA zone, full VTIMEZONE, local time with TZID, and UTC only where the standard calls for it. When AddCal imports someone else's feed into a [subscription calendar](https://addcal.co/solutions/subscription-calendars.md), it repairs the two broken shapes on the way in. Google's UTC-plus-header exports are re-read in the calendar's declared zone so the wall clock matches what the owner sees, and floating times are anchored to the calendar's zone rather than shifted. If you just need a single correct file right now, the free [ICS generator](https://addcal.co/tools/ics-generator.md) makes one with the zone handled, no account needed. And if the file is fine and the import itself is the problem, [how to add an ICS file to Google Calendar](https://addcal.co/blog/how-to-add-an-ics-file-to-google-calendar.md) covers the import paths. Last updated on September 30, 2026 ![Tom](https://cdn.addcal.co/static/authors/atymic.jpg)### Tom Founder Built Calndr.link in 2020 because an event link broke in Outlook and it annoyed him enough to fix it properly. Six years later he can tell you exactly how each calendar app mangles a timezone, which is a worse party trick than it sounds. Otherwise found hanging off a rock somewhere in Australia. [GitHub](https://github.com/atymic)[X](https://x.com/atymic) ### Related articles [How to Send a Calendar Invite (Any Calendar App) What a calendar invite actually is under the hood, how to send one properly in Google Calendar, Outlook, Apple Calendar and Gmail, the etiquette that gets people to accept, and why cross-organisation invites so often fail.](https://addcal.co/blog/how-to-send-a-calendar-invite.md)[Add to Calendar Link Not Working on iPhone? Why, and the Fix Tap Add to Calendar on an iPhone from Facebook, Instagram or WhatsApp and nothing happens. The link is fine; the in-app browser cannot hand a file to Calendar. How to tell which browser you are in, the fix, and how to build a link that works anyway.](https://addcal.co/blog/add-to-calendar-link-not-working-on-iphone.md)[How to Accept a Google Calendar Invite Every way to RSVP to a Google Calendar invite, from Gmail, the web and mobile, plus adding a note, proposing a new time, changing your answer, and finding invites that never arrived.](https://addcal.co/blog/how-to-accept-a-google-calendar-invite.md) [ Browse all articles ](https://addcal.co/blog.md)