Microsoft Bookings - shared booking page: malformed VTIMEZONE in confirmation email .ics attachment

Question

Summary

The booking.ics file attached to Bookings confirmation emails contains a VTIMEZONE component with no recurrence rules defining the DST transitions. Calendar clients that resolve TZID from the file cannot determine which UTC offset applies and fall back to standard time, placing the appointment one hour late for the duration of daylight saving. The email body shows the correct time; only the attachment is wrong.

 

Environment

Microsoft Bookings, shared booking page. Business time zone (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Attachment PRODID:Microsoft Exchange Server 2010, METHOD:PUBLISH.

 

Steps to reproduce

1. Create a shared booking page with the business time zone set to GMT Standard Time.
2. Book any appointment on a date falling within British Summer Time.
3. Open the confirmation email in a client that parses VTIMEZONE from the file — Gmail, Apple Mail, or Android Calendar.
4. Open the attached booking.ics.

Expected — appointment appears at the booked time, matching the email body.

Actual — appointment appears one hour later than the booked time.

 

Root cause

The VTIMEZONE emitted in the confirmation attachment:

BEGIN:VTIMEZONE

TZID:GMT Standard Time

BEGIN:STANDARD

DTSTART:16010101T000000

TZOFFSETFROM:+0100

TZOFFSETTO:+0000

END:STANDARD

BEGIN:DAYLIGHT

DTSTART:16010101T000000

TZOFFSETFROM:+0000

TZOFFSETTO:+0100

END:DAYLIGHT

END:VTIMEZONE

 

Both sub-components declare the same DTSTART and neither carries an RRULE, so the file provides no basis for selecting an observance. Per RFC 5545 §3.6.5, the recurrence rules are what define when each offset takes effect.

 

The calendar invitation generated for the same booking contains the correct definition:

BEGIN:STANDARD

DTSTART:16010101T020000

TZOFFSETFROM:+0100

TZOFFSETTO:+0000

RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10

END:STANDARD

BEGIN:DAYLIGHT

DTSTART:16010101T010000

TZOFFSETFROM:+0000

TZOFFSETTO:+0100

RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3

END:DAYLIGHT

 

The stored event time is correct in both files (DTSTART;TZID=GMT Standard Time:20260807T110000). The fault is confined to the timezone definition in the METHOD:PUBLISH serializer used by the confirmation path.

 

Impact and scope

Affects any tenant in a DST-observing time zone, for the duration of DST. Outlook resolves GMT Standard Time from the Windows time zone table and renders correctly, which masks the fault for most internal testing; third-party clients that follow the file do not. Customers receiving both emails may add the wrong one. The confirmation email cannot be disabled — only the calendar invitation can — so there is no configuration that avoids sending the malformed file.

 

Prior report

This root cause was identified and reported on Microsoft Q&A in April 2024 ("Microsoft Bookings .ics file shows different times depending on calendar app used to open it"), including confirmation that adding the missing RRULEs resolved the behaviour in Apple Mail. No fix has shipped.

Answer 1

Hi @Richard Jordan

Thank you for the detailed analysis and information provided.

Based on your findings, this appears to be related to how the Bookings confirmation ICS attachment handles daylight saving time (BST/DST). While the appointment time itself seems to be stored correctly, some third-party calendar clients rely on the VTIMEZONE definition included in the ICS file. If the DST transition rules are missing, those clients may interpret the event using the standard GMT offset, resulting in a one-hour time shift.

As this is a user-to-user community forum, contributors here do not have the ability to directly engage Microsoft product, Therefore, I recommend opening a case with Microsoft Support for further investigation. Please include your reproduction steps, sample ICS files, and root cause analysis, as these will be valuable for the investigation.

You can open a support ticket via Admin Center.

Unfortunately, I apologize for being unable to resolve this issue directly from the community forum, but the information you've gathered, including the sample ICS files, reproduction steps, and root cause analysis, should provide a strong basis for a support investigation.