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 · Converting UTC in Power Automate · Handling it in REST API calls · When would you actually use this?

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.

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.

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