SharePoint Time zones: Overview and Implementation Approaches

SharePoint stores dates in UTC and displays them based on the site’s regional settings — get that mismatched, and you get list items showing the wrong time, or a Power Automate flow firing at the wrong hour.

In this post: Why this happens · The “Date Only” field gotcha · Fixing list view display · The personal override users don’t know they have · Auditing time zone drift across many sites · Converting UTC in Power Automate · Handling it in REST API calls · When would you actually use this? · Related reading

Why this happens

Every date field SharePoint generates internally — Created, Modified — is stored in UTC, full stop. The site’s regional time zone setting is purely a display layer on top of that: it tells the browser-rendered list view how to convert UTC to local time for a human reading it. It does not change what’s actually stored, and it doesn’t apply anywhere outside the standard list view UI — not in calculated columns evaluating [Today], not in Power Automate triggers, not in REST API responses. Anything reading the raw value gets UTC and has to convert it itself.

The “Date Only” field gotcha

This is the specific, well-known bug this UTC storage behavior causes in practice. A column set to Date Only (no time component shown) actually stores midnight, local time, converted to UTC underneath — same as any other date field. For anyone in a time zone behind UTC (most of the Americas), midnight local time converts to the previous day in UTC. Read that raw value back in Power BI, a Power Automate flow, or any tool that doesn’t reapply the site’s regional offset before displaying it, and a date entered as September 22 shows up as September 21 — consistently, not intermittently, because it’s a real storage-and-conversion effect, not a rendering glitch. The practical fix: if a “Date Only” field is feeding into something outside the standard SharePoint list view, explicitly convert it back to local time before displaying or comparing it, exactly like the Power Automate and REST examples below — don’t assume “Date Only” means “time zone doesn’t apply here.”

Fixing list view display

Site Settings > Regional Settings.
Select the correct time zone.
Save and verify against a known list item.

The personal override users don’t know they have

Worth ruling out before assuming a site’s regional setting is wrong just because one person reports odd times: every user can override the site’s regional setting for their own view, via their profile’s Language and Region page (profile picture > My Microsoft 365 profile > Language and Region), by checking Always use my personal settings and picking their own locale and time zone there. Once set, that user sees dates and times converted using their personal setting instead of the site’s, everywhere the standard list view UI applies it — and nobody else’s view changes at all.

This explains a specific, confusing support ticket: one person seeing times off by a few hours while everyone else on the same site sees them correctly. The fix isn’t touching the site’s regional settings at all (that would break it for everyone else) — it’s checking whether that one user has a personal override set, and correcting or clearing it in their own profile instead. It’s also a real limitation worth knowing before promising a fix: this setting is entirely per-user and self-service, so there’s no admin-side way to set or force it for someone else, or to audit who’s turned it on across a tenant.

Auditing time zone drift across many sites

The 3-click fix above works fine for one site. It stops being practical once a tenant has grown past a couple dozen sites — new sites default to whatever regional setting the tenant or hub template specified at creation, and in a multi-region org (a US HQ provisioning a site for a UK or APAC team, say) that default is wrong more often than it’s right. Nobody usually notices until someone points out their timestamps are off by 5-8 hours. Auditing every site’s time zone by opening Site Settings one at a time doesn’t scale; pulling it via PnP PowerShell does:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive

$web = Get-PnPWeb -Includes RegionalSettings, RegionalSettings.TimeZone
"$($web.Url) -> $($web.RegionalSettings.TimeZone.Description)"

Loop that across every site in the tenant (via Get-PnPTenantSite) to build a real inventory of what’s actually set, rather than assuming the tenant default applied everywhere. Fixing a site that’s drifted needs the full timezone collection, not just the current value, since the available IDs are enumerated per web:

$web = Get-PnPWeb -Includes RegionalSettings, RegionalSettings.TimeZones
$targetZone = $web.RegionalSettings.TimeZones | Where-Object { $_.Description -like "*Eastern Time*" }
$web.RegionalSettings.TimeZone = $targetZone
$web.Update()
Invoke-PnPQuery

Worth running this as a scheduled audit rather than a one-time cleanup — new sites keep getting created with the wrong regional default until whatever’s driving the tenant’s site-creation flow gets fixed at the source, so drift comes back.

Converting UTC in Power Automate

SharePoint timestamps pulled into a flow are still UTC until you convert them:

convertTimeZone(triggerOutputs()?['body/Created'], 'UTC', 'Eastern Standard Time')

Without this, conditions and notifications keyed off “morning” or “end of day” will fire at the wrong actual time for anyone outside UTC.

Handling it in REST API calls

Same problem shows up in custom SPFx web parts or third-party integrations pulling date fields directly:

let utcDate = new Date(item.Created);
let localDate = utcDate.toLocaleString('en-US', { timeZone: 'America/New_York' });

SharePoint dates are UTC under the hood — convert explicitly in flows and API calls, don’t assume the site’s regional setting handles it for you outside the UI.

When would you actually use this?

A list view is showing times that are off by several hours — almost always a regional settings mismatch, fixable in 3 clicks.
A Power Automate flow is firing at the wrong actual local time — the trigger timestamp is UTC and needs explicit conversion, not implicit assumption.
You’re building an SPFx web part or custom integration and dates look wrong to users in different time zones — convert explicitly in code, don’t rely on the browser’s default.

What You Need to Know About SharePoint Administration — time zone settings are one small piece of the broader admin picture covered here.
Store and Display Dates Properly in JavaScript — the client-side half of getting dates and times right once SharePoint hands them to your code.

That’s the gist of it. Got questions? Drop them below.