Confimations show wrong time zone - Is it the fault of Cal.com or my calendar tool (Kerio)?

[saschafoerster]

Hi! Sometimes people complain about our confirmation e-mails, when a new appointment is made.
We are GMT+2, but the date in the email is GMT+0, so most people, who are not working with timezones show up 2 hours to early or ask, why we moved the appointment.

The setup:

• We have a self hosted Cal.com
• We use a self hosted Kerio Connect: https://gfi.ai/products-and-solutions/email-and-messaging-solutions/kerioconnect

We connected Kerio to Cal.com with iCal. So every appointments gets first checked with my calendar and then get's added.
Cal.Com is sending a confirmation e-mail. That e-mail is (kind of) correct in GMT+2 (we should have times in 24 not in 12(am/pm):

The confirmation email from Kerio is showing the appointment in GMT+0! That is confusing people:

So I thought, the fault is with Kerio. But when I create an appointment manually in Kerio, Kerio is using GMT+2:

So I wonder, what needs to change, so that people don't get confused by the timezones:

• A: Cal.com needs to send a different iCal entry, that is not using GMT+0 but the time in GMT+2 so that the emails gets send from Kerio correctly.
• B: It is Kerios fault, the should only send confimation emails with the timezone of the server or have an option to change the email sent from the system.
• C: I have another idea. :)

[dosubot[bot]]

Based on the code and discussions, Cal.com generates iCal (ICS) files with event times in UTC (GMT+0), even though it includes the organizer's timezone in the event metadata. This means when Kerio imports these events, it may display the appointment in GMT+0 if it doesn't interpret the timezone metadata or TZID correctly, which matches what you're seeing. When you create events directly in Kerio, it uses your local timezone (GMT+2), so the confirmation emails look correct.

To avoid confusion, Cal.com would need to generate iCal files that use the local timezone explicitly (with TZID) for event times, not just UTC. Alternatively, if Kerio has an option to interpret incoming iCal events in the user's or server's timezone, enabling that could help, but the root cause is likely the way Cal.com formats the ICS file times in UTC rather than your local timezone. This is a common issue with calendar integrations when timezone handling isn't fully aligned between systems.

You can see the relevant code and discussion here:
Cal.com builds calendar events using UTC for start and end times, and includes the organizer's timezone in metadata, but the ICS event times themselves are in UTC.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[saschafoerster]

@dosu Can you show me the code parts, where the iCal file is generated?

[dosubot[bot]]

The main code responsible for generating iCal (ICS) files in Cal.com is the generateIcs function, located in packages/lib/bookings/ics.ts. This function builds the ICS file using the ical-generator library, setting event start/end times (usually in UTC) and embedding timezone information (like TZID and VTIMEZONE blocks) if configured. The way these fields are set determines how external calendar tools (like Kerio) interpret the event time and timezone. If the ICS file lacks proper TZID or VTIMEZONE info, clients may default to GMT+0, which can cause the issue you described.

If you want to review or adjust how timezones are handled, packages/lib/bookings/ics.ts and the generateIcs function are the key places to look. The timezone logic there is crucial for compatibility with external calendar tools.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[saschafoerster]

#22872 could be related.

Problem:

iCal event strings lacked VTIMEZONE definitions, causing times to appear in UTC rather than the user's local timezone.

Solution:

Generate full VTIMEZONE blocks with support for DST using helper methods (generateTimezoneBlock, getTimezoneOffset, getTimezoneOffsetMs).