Calendar/Event ICS export: wrong time (+1 h) when importing into Outlook with TZID=Europe/Berlin

Contribute Bug
1

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.
[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):

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).

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.

2 Likes
3

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:

timedatectl set-timezone Europe/London

and my app.yml contains:

- 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:

timedatectl set-timezone Europe/Berlin

and, in run: section,

- 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.

4

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 :see_no_evil_monkey:

5

I’ve investigated this further and opened a PR to address it:

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.

1 Like