# Calendar/Event ICS export: wrong time (+1 h) when importing into Outlook with TZID=Europe/Berlin
**URL:** https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797
**Category:** Bug
**Tags:** events, fixed
**Created:** [11 augustus 2026 om 14:29 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797 "2026-08-11T14:29:03Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Michael\_D](https://meta.discourse.org/u/Michael_D)
#### Post date: [11 augustus 2026 om 14:29 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797/1 "2026-08-11T14:29:03Z")
**Version:** Discourse 2026.1.5 (ESR), discourse-calendar plugin
**Summary**
New events created with a set timezone (`timezone="Europe/Berlin"` and `showLocalTime="true"`) show the wrong time by **+1 hour** when downloading the `.ics` file and importing it into **Outlook (Windows)**. The time is correct in the forum itself. Only new events are affected, i.e. the import via the `.ics` file.
**Reproduction**
1. Create an event (today, in daylight saving time CEST/UTC+2): 5:00 PM – 7:15 PM Berlin time.
```plaintext
[event start="2026-08-11 17:00" status="public" name="testevent 2" timezone="Europe/Berlin" showLocalTime="true" end="2026-08-11 19:15"]
[/event]
```
1. “Add to calendar” → download the `.ics` file.
2. Import the file into Outlook.
**Expected:** 11.08.2026, 17:00 – 19:15
**Actual:** 11.08.2026, **18:00 – 20:15** (+1 hour)
**ICS content (relevant):**
```plaintext
DTSTART;TZID=Europe/Berlin:20260811T170000
DTEND;TZID=Europe/Berlin:20260811T191500
```
_(The file does not contain a `VTIMEZONE` block for `Europe/Berlin`.)_
**Analysis / Suspected cause**
The export specifies the time locally with `TZID=Europe/Berlin` (IANA name) instead of UTC (`...Z`). Outlook doesn’t understand IANA timezone names (it uses Windows identifiers such as “W. Europe Standard Time”) and, without a `VTIMEZONE` definition, falls back to the fixed offset **UTC+1 (CET/winter time)**. During summer time (CEST = UTC+2) this results in exactly **+1 hour**. Cross-check: importing the same file into Google Calendar (which understands IANA timezones natively) shows the correct 17:00.
Suggestion: the ICS export should either use UTC timestamps with `Z` or generate a complete `VTIMEZONE` block including DST rules (see also the discussion on ICS spec adherence in [LOCATION is not available in full ICS export](https://meta.discourse.org/t/location-is-not-available-in-full-ics-export/387771)).
**Additional observation:** When the same event is created **without** `timezone=`/`showLocalTime`, the exported `.ics` uses UTC and Outlook shows **+2 hours** (since 17:00 UTC = 19:00 CEST). This is the documented UTC behavior, but it further illustrates that the timezone handling around the ICS export is confusing for users expecting local times.
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [11 augustus 2026 om 16:10 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797/3 "2026-08-11T16:10:57Z")
For comparison, I have been running my Discourse host and app container in the local IANA timezone rather than UTC because of previous calendar timezone behaviour.
My host is set with:
```plaintext
timedatectl set-timezone Europe/London
```
and my `app.yml` contains:
```yml
- exec: ln -fs /usr/share/zoneinfo/Europe/London /etc/localtime
- exec: dpkg-reconfigure --frontend noninteractive tzdata
```
This means both my host and Discourse container use Europe/London, including the automatic GMT/BST change.
It may be worth testing the equivalent with Europe/Berlin on your installation to see whether the resulting `.ics` imports correctly into Outlook:
```plaintext
timedatectl set-timezone Europe/Berlin
```
and, in `run:` section,
```yml
- exec: ln -fs /usr/share/zoneinfo/Europe/Berlin /etc/localtime
- exec: dpkg-reconfigure --frontend noninteractive tzdata
```
I would be interested to know whether that changes your 17:00 Berlin event from importing at 18:00 to the expected 17:00.
If it does, that would suggest the Discourse/container timezone is influencing the export; if it does not, the missing VTIMEZONE/Outlook handling is likely independent of the server timezone.
---
### Author:  [@Tonja](https://meta.discourse.org/u/Tonja)
#### Post date: [2 september 2026 om 07:53 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797/4 "2026-09-02T07:53:11Z")
We’re experiencing exactly this issue as well.
**Reproduction:**
- Event created with `timezone="Europe/Berlin"` and `showLocalTime="true"`, during CEST (summer time).
- Downloaded the `.ics` file via “Add to calendar” and imported it into Outlook.
**Actual result:** Event shows +1 hour off (e.g. 17:00 Berlin time appears as 18:00 in Outlook).
**Expected result:** Event should show 17:00 as entered.
We can confirm this happens consistently, not intermittently for events happening during CEST. Other Events outside CEST aren’t affected.
We would be really happy to see this issue fixed, since our users can be very sensitive to malfunctions 🙈
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [3 september 2026 om 10:10 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797/5 "2026-09-03T10:10:56Z")
I’ve investigated this further and opened a PR to address it:
>
>
> \## What does this change?
>
> Adds \`VTIMEZONE\` components to generated ICS downlo…ads when an event uses a named timezone.
>
> Some calendar clients, notably Outlook on Windows, do not reliably interpret IANA \`TZID\` values unless the calendar also includes a matching \`VTIMEZONE\` definition. This could cause events such as \`Europe/Berlin\` to import one hour late even though the \`DTSTART\`/\`DTEND\` values were correct.
>
> The generator now derives the current timezone rules from the bundled Moment Timezone data and:
>
> emits one \`VTIMEZONE\` per unique \`TZID\`
> emits the current recurring \`DAYLIGHT\` / \`STANDARD\` pair using open-ended yearly \`RRULE\`s when the transition rules are stable
> verifies that the following seasonal cycle repeats the same rules before treating them as recurring
> falls back to the current fixed offset when a stable recurring pair cannot be established
> handles zones with no current DST transition
>
> Existing event \`DTSTART\` / \`DTEND\` behavior is unchanged; the additional timezone definition gives clients the information needed to interpret those local times correctly.
>
> \## Tests
>
> Added coverage for:
>
> \- \`Europe/Berlin\` — European DST rules / original Outlook case
> \- \`America/New\_York\` — North American DST rules
> \- \`Asia/Kolkata\` — stable current offset
> \- \`Europe/London\` — zero standard UTC offset / GMT-BST rules
>
> \`Unit | Utility | download-calendar\`: 22/22 passing.
>
> \`discourse-events\` QUnit: 270 passing, 1 skipped, 0 failures.
>
> Prettier, ESLint, and \`git diff --check\` are clean.
The issue is in the ICS export rather than the server/container timezone. The exported event uses an IANA `TZID` such as `Europe/Berlin`, but currently doesn’t include the corresponding `VTIMEZONE` definition that clients such as Outlook need to interpret the daylight-saving rules reliably.
The PR adds `VTIMEZONE` definitions to timezone-aware ICS downloads while keeping the existing local `DTSTART`/`DTEND` values.
For the example from this topic, the export now includes the CET/CEST observances for `Europe/Berlin`, so:
`DTSTART;TZID=Europe/Berlin:20260811T170000`
can be interpreted with the correct UTC+2 summer offset rather than Outlook falling back to UTC+1.
I’ve also added coverage for European and North American DST rules, a fixed-offset case, and the more unusual seasonal transitions used by `Africa/Casablanca`.
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [15 september 2026 om 15:05 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797/6 "2026-09-15T15:05:59Z")
@Michael_D @Tonja a fix has been merged, should land on `latest` soon 👍
---
### Author:  [@tannerabread](https://meta.discourse.org/u/tannerabread)
#### Post date: [15 september 2026 om 15:06 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797/7 "2026-09-15T15:06:54Z")
I was watching the pipeline as you were typing. Fix is now in `latest`. Thank you for your contribution @Ethsim2!
---
### Author:  [@Tonja](https://meta.discourse.org/u/Tonja)
#### Post date: [15 september 2026 om 15:08 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797/9 "2026-09-15T15:08:54Z")
Thanks a lot @Ethsim2 and @tannerabread 🥳
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [17 september 2026 om 15:10 UTC](https://meta.discourse.org/t/calendar-event-ics-export-wrong-time-1-h-when-importing-into-outlook-with-tzid-europe-berlin/409797/10 "2026-09-17T15:10:53Z")