SharePoint Online Events ignore user time zone and DST when site regional settings are set to UTC

Kristen Scott 20 Reputation points
2026-04-13T16:27:04.4433333+00:00

Issue Description

We are experiencing unexpected and inconsistent time zone behavior when creating and viewing events in SharePoint Online, both via the Microsoft Graph API and directly through the SharePoint UI.

When the SharePoint site regional settings are set to UTC, event times appear to be treated as UTC end‑to‑end. User profile time zones and Daylight Saving Time (DST) are not applied during rendering, resulting in incorrect event times being displayed.

Environment Details

SharePoint site regional settings: (UTC) Dublin, Edinburgh, Lisbon, London

Event creation methods:

  • Microsoft Graph API (UTC timestamps)
  • SharePoint UI (date/time picker) 
    **User profile time zone:** Central Time (DST‑aware)
    Primary business time zones: [Moderator note: personal info removed] 

Graph API Reproduction

Input Sent to SharePoint via API

Plain Text

Start (EventDate): 2026-04-21T17:00:00.000000+00:00

End (EndDate): 2026-04-21T18:00:00.000000+00:00

``

Show more lines

Expected Behavior

April 21 is during Daylight Saving Time.

Central Time on this date is CDT (UTC‑5).

  • 17:00 UTC → 12:00 PM CDT
  • 18:00 UTC → 1:00 PM CDT

Expected display: ✅ 12:00–1:00 PM

Actual Behavior

  • The event displays in SharePoint as 6:00–7:00 PM
  • No user time zone offset is applied
  • No DST adjustment is applied

This suggests the event is rendered strictly as UTC, despite the viewing user being set to a DST‑aware time zone.

SharePoint UI Reproduction (Confirms Same Behavior)

Steps

  1. Create an event directly in SharePoint using the date/time picker
  2. Enter 12:00–1:00 PM
  3. Save the event
  4. View the event on the calendar

Observed Result

  • The event appears as 5:00–6:00 PM

This indicates that the SharePoint UI is also treating entered times as site time zone (UTC) rather than converting from the user’s local time zone.

Summary

  • Event times appear to be site‑time‑zone authoritative
  • User profile time zones are ignored
  • DST is not applied
  • Behavior is consistent across:
    • Microsoft Graph API–created events
      • SharePoint UI–created events
Microsoft 365 and Office | SharePoint | For business | MacOS
Answer accepted by question author
Chris Duong 10,705 Reputation points Microsoft External Staff Moderator
2026-04-13T17:16:27.2266667+00:00

Hi @Kristen Scott, 

Good day, and I appreciate the clear details of your concern and the thorough reproduction steps. 

Based on what you shared, the behavior you’re seeing is consistent with how SharePoint Online calendars/events render date/time values when a site’s regional time zone is configured specifically, the calendar view is treating the site regional time zone as the authoritative time zone for display, rather than converting the event time to each viewer’s user/profile time zone (including DST adjustments for the viewer).

A - What’s happening  

1/ The calendar is rendering using the site’s regional time zone 

Your site is configured with the regional setting (UTC) Dublin, Edinburgh, Lisbon, London. Although it includes the “UTC” label, this is not a fixed UTC (no‑DST) time zone. It follows UK/Ireland rules and observes Daylight Saving Time (BST). 

As a result, SharePoint calendar displays event times based on the site’s time zone, rather than converting them to the viewer’s Central/Eastern time zone. 

2/ Why the Graph-created event displays as 6:00-7:00 PM 

The event was created using UTC timestamps (17:00-18:00 UTC). On April 21, the Dublin/London time zone is in DST (UTC+1), so the calendar displays: 

  • 17:00 UTC > 18:00 (6:00 PM) site time 
  • 18:00 UTC > 19:00 (7:00 PM) site time 

This matches the observed behavior. The data sent via Graph is valid UTC; the difference comes from site-time-zone-based rendering. 

3/ Why the SharePoint UI-created event also shifts 

When events are created using the SharePoint date/time picker, the entered time may be interpreted and stored relative to the site time zone, and the calendar then renders it again using that same site time zone. As a result, events entered expecting Central time (for example, 12:00-1:00 PM) may appear later, because the calendar does not consistently apply the viewer’s profile time zone. 

More info here: Change regional settings for a site - Microsoft Support 

B - Practical workarounds 

Below are approaches customers commonly use depending on the desired outcome: 

Option 1 - If the calendar should display in a single “business” time zone 

Please set the SharePoint site regional time zone to the intended business time zone (e.g., Central or Eastern). 

This ensures the calendar shows times consistently for everyone in that standard. 

Note: Not per-user localization 

Option 2 - If the requirement is per-user time zone rendering (Central/Eastern per viewer) 

SharePoint Events/Calendar views (especially in modern experiences) may not reliably render times per viewer’s profile time zone. 

If per-user localization is a strict requirement, recommended alternatives include: 

  • Using Outlook/Exchange calendars for scheduling across time zones (designed for per-user time zone and DST handling) 
  • Implementing a custom front-end (e.g., SPFx / Power Apps) that explicitly converts and displays times in the viewer’s time zone 
  • This option may require adoption of Exchange calendar or custom UI 

Option 3 - Store “reference” time zone details alongside the event (Optional) 

If you need to keep SharePoint as the storage location, you can add supporting fields like: 

  • “Original time zone” (e.g., Central) 
  • “Local start time (text)” for clarity 
  • Or a computed display pattern in a custom view/page 

Note: More data/UX complexity 

For additional information, you or (your IT department) can refer to this article: Date and Time Column Behavior in SharePoint List/Library 

This link is shared by community members for your convenience. It points to a third-party site that is not managed or verified by Microsoft. We can’t guarantee the quality, safety, or suitability of any content or software found there. Please review carefully and make sure you understand any potential risks before using it. 

C - Contact Microsoft Support   

If the issue persists even after these steps, it may stem from a deeper system-level cause. In this case, I recommend contacting your organization's IT administrator, who can submit a support request to Microsoft through the Microsoft 365 Admin Center. They’ll be able to access system-level information to investigate the issue thoroughly and provide assistance. At the very least, they can offer the most effective workaround to ensure your experience remains smooth and secure.      

As community moderators, we appreciate your understanding that we do not have access to the administrative tools or permissions required to investigate or modify these configurations. We also do not have the capability to initiate remote sessions for direct assistance. Our role is to guide users to the appropriate resources and support channels.  

I hope this information is helpful. Should you have any further questions or need additional assistance, feel free to reach out.   

I look forward to hearing your thoughts on this. 

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have any extra questions about this answer, please click "Comment".  

Note: Follow the steps in our documentation to enable email notifications if you want to receive email notifications related to this topic.     

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-04-13T16:27:25.9+00:00

    SharePoint Online calendar event rendering is driven primarily by site and service time zone configuration, and there are known pitfalls when using UTC or DST‑mismatched zones.

    From the available information, the following points apply:

    1. When a region or service is configured with a time zone that observes DST while the actual usage pattern does not, Microsoft guidance is to avoid simply disabling DST and instead choose a time zone that has the same UTC offset but does not use DST. This is to prevent incorrect calendar times for users in other time zones.
      • Example: For a region that does not observe DST but is configured as (UTC‑06:00) Central Time (US and Canada), the recommendation is to switch to a non‑DST zone with the same offset, such as (UTC‑06:00) Central America or (UTC‑06:00) Saskatchewan, instead of clearing “Automatically adjust clock for Daylight Saving Time.”
    2. In multi‑service scenarios (Exchange/Outlook/SharePoint), user‑level regional settings are the preferred way to control how times are displayed across Microsoft 365 services. Changing tenant‑ or admin‑level time zone settings can cause timestamp misalignments in admin views and across services.
      • The recommendation is to rely on user‑level time zone and locale settings for Outlook, SharePoint, and other Microsoft 365 services, rather than overriding the central admin time zone.
    3. When the server or service time zone is in a DST‑observing region but the effective usage pattern is different, incorrect “Sent” or meeting times can occur in Outlook on the web. The documented workaround is to set the server’s time zone to a region with the same UTC offset that does not follow DST.

    Applied to the described SharePoint Online behavior:

    • Using a site regional setting of (UTC) Dublin, Edinburgh, Lisbon, London (a DST‑observing zone) while expecting user‑profile time zones (Central/Eastern) and DST to be applied differently can lead to misaligned calendar times.
    • The observed behavior—events being treated as UTC end‑to‑end and ignoring user profile time zones—matches the class of issues where the service’s base time zone configuration conflicts with how DST and offsets are expected to work.

    Mitigation options consistent with the documented guidance are:

    1. Avoid using a DST‑observing zone as the “authoritative” site time zone when the intent is to treat stored times as pure UTC and then rely on user time zones for display.
    2. Where possible, use user‑level regional settings (time zone and locale) to control display, and avoid overriding time zone behavior at the site/admin level in ways that conflict with how users expect DST to apply.
    3. If the effective business requirement is “no DST shift at the storage/site level,” choose a time zone with the same UTC offset that does not observe DST, rather than relying on a DST‑aware zone and expecting the service to ignore DST.

    These patterns are the supported way to avoid incorrect calendar times when DST and time zone configurations interact across Microsoft 365 services.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.