Azure Logic Apps Standard – Impact of B.C. Permanent Pacific Time Change on convertFromUtc() Effective November 1, 2026

Question

Azure Logic Apps Standard – Impact of B.C. Permanent Pacific Time Change on convertFromUtc() Effective November 1, 2026

Ravulapalli, Teja 0

We are using Azure Logic Apps Standard and have the following expression in our workflow:

formatDateTime(

convertFromUtc(

    body('Parse_Key_Fields')?['DOCDATE'],

    '**Pacific Standard Time'**

),

'yyyy-MM-dd HH:mm:ss'

)

Could you please clarify the following?

Will the existing Windows time-zone identifier Pacific Standard Time automatically follow British Columbia's new permanent UTC−7 offset in Azure Logic Apps Standard, or will it continue applying the traditional Pacific daylight-saving rules and switch to UTC−8 on November 1, 2026?
Is the new Windows time-zone identifier British Columbia Standard Time supported by the convertFromUtc() expression in Azure Logic Apps Standard? If so, from what date will it be available in the runtime?
Does the behavior depend on the Logic Apps Standard hosting environment, operating system, or time-zone database updates?
What is Microsoft's recommended approach to ensure that convertFromUtc() consistently converts UTC timestamps to British Columbia local time (UTC−7 year-round), including dates after November 1, 2026?
Is any configuration change, runtime update, or application redeployment required to ensure correct date/time conversion?

We would appreciate confirmation of the expected behavior and a Microsoft-recommended solution before the November 1, 2026 transition, as incorrect time conversion could affect our downstream processing.

Thank you for your assistance.

0 comments

1 answer

Your answer

Answer 1

Hi @Ravulapalli, Teja

Short answer: don't rely on Pacific Standard Time for British Columbia after November 1. That Windows ID keeps the US Pacific daylight-saving rules, so it will move to UTC−8 on November 1 like Washington and California. That's wrong for B.C. once it stays on UTC−7.

Here's what Microsoft has published so far:

Windows has a new ID, British Columbia Standard Time (UTC−07:00), released in a Windows time zone update in October 2026.
Microsoft's guidance for Canada's 2026 changes recommends using Yukon Standard Time as the interim substitute for most of B.C. until the new ID is available where you run, and to switch to the final ID later. It also warns: don't blanket-replace historical conversions, because the substitute only matches current and future offsets.

For your workflow, I'd do this:

Make a small test workflow in your Logic Apps Standard app that runs convertFromUtc('2026-11-15T20:00:00Z', 'British Columbia Standard Time').
If it returns 13:00 (UTC−7, not 12:00), the runtime already has the new ID, so use it in your expression.
If it throws an invalid time zone error, use 'Yukon Standard Time' for timestamps on or after November 1, 2026, and keep 'Pacific Standard Time' for older DOCDATE values. Add a condition on the date if your data mixes both.
Re-test after future platform updates, and switch to British Columbia Standard Time once it resolves.

The result depends on the time zone data in the host OS and runtime, which is why I'd test rather than assume.

Do your DOCDATE values include historical dates before November 1, or only new transactions?

If your conversions come out right, please consider accepting it as the answer. If neither ID behaves as expected in your test, let me know and I'll be happy to keep helping.

Reference:

Ravulapalli, Teja 0 Reputation points

2026-10-29T14:25:40.7066667+00:00

Thanks @Rukshan edirisinghe for looking into this and for the detailed explanation!

Would you recommend using the following expression as an alternative for converting DOCDATE to British Columbia local time (UTC−7) after November 1, 2026?

text

formatDateTime(addHours(body('Parse_Key_Fields')?['DOCDATE'], -7), 'yyyy-MM-dd HH:mm:ss')

Would this be a reliable approach, or would you recommend using convertFromUtc() with Yukon Standard Time or British Columbia Standard Time instead?

Thanks again for your help!
Rukshan edirisinghe 2,365 Reputation points

2026-10-30T03:43:11.28+00:00

Yes, a fixed −7 hours is a reliable approach for B.C. from November 1, 2026 onward. The province is staying on UTC−7 all year, so there are no daylight-saving changes to handle. A fixed offset also doesn’t depend on which time zone data your Logic Apps host has, which makes it simpler than convertFromUtc() right now.

Check three things before you rely on it:

DOCDATE must be a UTC timestamp. If Business Central sends it already in local time, subtracting 7 hours shifts it twice.

Watch out for date-only values. If DOCDATE is a plain date like 2026-11-15, it’s read as midnight UTC. Subtracting 7 hours turns it into 2026-11-14 17:00, so the date moves back a day. If it has no time part, don’t convert it at all.

Older records. For winter dates before November 1, 2026, B.C. was on UTC−8, so −7 would be one hour off. If your data includes those dates, add a condition: use convertFromUtc(..., 'Pacific Standard Time') before November 1 and addHours(..., -7) from November 1.

Once your runtime supports British Columbia Standard Time, you can switch to convertFromUtc() with that ID. That’s optional, since your expression will keep giving the correct result.