I recently had a flow where I set a date to 10:00 & SharePoint showed 11:00.
No calculations. No formatting. Just a simple update. That’s exactly what makes this issue so confusing: everything looks correct, but the result isn’t.
This is not a “date issue”, it’s a timezone issue. More specifically:
“Dates are passed through services in varying formats or time zones, so each connector might use a different datetime format or time zone.” – Microsoft Learn
Which means you’re rarely working with just a date, you are working with a timestamp & its time zone context. & if that context is missing or misunderstood, things go wrong very quickly.
What Power Automate actually does
So, Power Automate works internally with UTC. When you use something like: utcNow()
you are getting UTC time, not your local time.
At the same time systems like SharePoint store or return values in UTC, but display them in your local time zone or according to your regional settings /_layouts/15/regionalsetng.aspx in the site settings.
So, what happens is that your flow sends UTC, SharePoint displays your regional settings & that’s when you might see a shift – often +1 or +2 hours.
Why does this get confusing fast?
Because not every date you get looks like UTC. You will usually run into three types of values:
Definitely UTC2026-03-24T09:00:00Z
The z means UTC (It actually stands for Zulu time). This one is the safe one, you know exactly what you are dealing with.
Offset-aware2026-03-24T10:00:00+01:00
This includes the time zone information, which is also safe, as it is fully defined.
Ambiguous 2026-03-24T10:00:00
No z, no offset. That’s the dangerous one, as it looks like regional/local time.. but it might not be.
What really causes issues
As stated earlier, the same field can behave differently depending on where it comes from. Examples:
- SharePoint usually returns UTC.
- Outlook is often tied to a mailbox time zone.
- Forms does not have any time zone context. For most fields we only get date fields or plain strings.
- APIs: Anything from clean UTC to “good luck”. 😄
The mistake I have made more than once
Let’s take a very typical scenario. You get a value from a connector (SPO, Forms, API, whatever) & it looks like this: 2026-03-24T10:00:00
At first glance that looks perfectly fine, so you think: “That’s 10:00 – exactly what I want.” But that’s the mistake. Because what you are actually seeing is just a time without any information about which time zone it belogs to.
So, now you are making an assumption: maybe it’s a local time, maybe it’s UTC or maybe it was even already converted somewhere earlier, but the value itself does not tell you.
What can actually go wrong from here
Let’s say this value represents UTC, but you assume it’s local time.
Scenario 1: No conversion
You pass it directly into SharePoint. Power Automate treats it as UTC & SharePoint displays it as local time, which results in a time shift (e.g. +1 hour).
Scenario 2: You convert it
You assume it must be UTC, so you convert it & you run convertTimeZone(...). But the value was actually already in your regional time, which results again in a time shift, but not even more wrong.
Scenario 3: Mixed behaviour in the same flow
This is the worst one. 😄
You convert some values, don’t convert others, you have mixed sources, etc. You’ll end up with some times which are correct, some are gonna be off & you will definitely have a hard time debugging.
How I handle it
I treat most incoming values as UTC unless proven otherwise. I really avoid converting unless I know that I really need to & I only do that when I want to display values to users or write to systems where the local time matters.
By the way adding “+1 hour”, like addHours(utcNow(), 1)
What you always want to do it to convert it properly: telling Power Automate what the source time zone is & the target time zone, like:
convertTimeZone(utcNow(), 'UTC', 'W. Europe Standard Time')
In this case it automatically switches between winter & summer time & you don’t have to think about it.
Leave a Reply