{"id":7808,"date":"2026-10-14T22:21:10","date_gmt":"2026-10-15T05:21:10","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/azure-sql\/?p=7808"},"modified":"2026-10-14T22:21:10","modified_gmt":"2026-10-15T05:21:10","slug":"canadas-2026-time-zone-updates-guidance-for-microsoft-sql","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/azure-sql\/canadas-2026-time-zone-updates-guidance-for-microsoft-sql\/","title":{"rendered":"Canada\u2019s 2026 time zone updates: guidance for Microsoft SQL"},"content":{"rendered":"

Affected locations in British Columbia, Alberta, and Manitoba will <\/span>not turn their clocks back at 02:00 local time on November 1, 2026<\/span><\/b>. They will remain at UTC\u221207:00, UTC\u221206:00, and UTC\u221205:00, respectively.<\/span>\u00a0<\/span><\/p>\n

Microsoft\u2019s interim guidance for <\/span>British Columbia<\/span><\/a>, <\/span>Alberta<\/span><\/a>, and <\/span>Manitoba<\/span><\/a> describes the new Windows time zones and temporary workarounds.<\/span>\u00a0<\/span><\/p>\n

SQL Server on Windows requires the applicable Windows update\u2014not a separate SQL Server product update.<\/span><\/b> For SQL Server on Linux, Azure SQL Database, and Azure SQL Managed Instance, the following guidance applies when the new regional time zones are not yet available in your deployment.<\/span>\u00a0<\/span><\/p>\n

Interim guidance when the new time zone is unavailable<\/span><\/b>\u00a0<\/span><\/p>\n

This table adapts the Windows interim guidance for SQL. Use the interim identifiers for explicit SQL conversions, SQL Database or eligible SQL Managed Instance database\/session settings, mapped Linux configuration, or <\/span>new SQL Managed Instances<\/span><\/b>. The instance-level time zone setting cannot be modified for\u00a0an existing\u00a0SQL\u00a0Managed Instance.<\/span>\u00a0<\/span><\/p>\n\n\n\n\n\n\n
Affected area<\/span><\/b>\u00a0<\/span><\/td>\nExisting SQL time zone<\/span><\/b>\u00a0<\/span><\/td>\nInterim SQL time zone<\/span><\/b>\u00a0<\/span><\/td>\nRequired offset from November 1<\/span><\/b>\u00a0<\/span><\/td>\nFinal regional time zone<\/span><\/b>\u00a0<\/span><\/td>\n<\/tr>\n
Most of British Columbia<\/span>\u00a0<\/span><\/td>\nPacific Standard Time<\/span>\u00a0<\/span><\/td>\nYukon Standard Time<\/span>\u00a0<\/span><\/td>\nUTC\u221207:00<\/span>\u00a0<\/span><\/td>\nBritish Columbia Standard Time<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Alberta and locations covered by its guidance*<\/span>\u00a0<\/span><\/td>\nMountain Standard Time<\/span>\u00a0<\/span><\/td>\nCanada Central Standard Time<\/span>\u00a0<\/span><\/td>\nUTC\u221206:00<\/span>\u00a0<\/span><\/td>\nAlberta Standard Time<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Manitoba<\/span>\u00a0<\/span><\/td>\nCentral Standard Time<\/span>\u00a0<\/span><\/td>\nEastern Standard Time (Mexico)<\/span>\u00a0<\/span><\/td>\nUTC\u221205:00<\/span>\u00a0<\/span><\/td>\nManitoba Standard Time<\/span>\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

*The Alberta guidance also covers southeastern BC locations aligning with Alberta and affected Northwest Territories locations, including Yellowknife and Inuvik. Do not apply the first row to all of BC.<\/span><\/i>\u00a0<\/span><\/p>\n

For Manitoba, the Windows workaround uses ordinary <\/span>Eastern Standard Time<\/span> with automatic DST adjustments disabled<\/span><\/b>. SQL\u2019s <\/span>AT TIME ZONE<\/span> does not provide the DST adjustment switch. Instead, <\/span>Eastern Standard Time (Mexico)<\/span> supplies UTC\u221205:00 without seasonal changes under its current rules. Ordinary <\/span>Eastern Standard Time<\/span> returns to UTC\u221204:00 in summer.<\/span>\u00a0<\/span><\/p>\n

Confirm that the selected identifier is available in <\/span>sys.time_zone_info<\/span> on the target deployment. These substitutes match the required current and future offsets, <\/span>not the provinces\u2019 complete historical rules<\/span><\/b>. Do not blanket-replace historical conversions. Move to the regional definition when supported, using the appropriate product-specific method.<\/span>\u00a0<\/span><\/p>\n

SQL Server on Windows<\/span><\/b>\u00a0<\/span><\/p>\n

SQL Server reads installed Windows time zones from the OS registry, as documented for <\/span>sys.time_zone_info<\/span><\/a>.<\/span>\u00a0<\/span><\/p>\n

Install the applicable Windows update. When the server\u2019s local time must follow the affected region, select the new regional zone under <\/span>Settings > Time & language > Date & time<\/span><\/b>, following the provincial guidance linked above.<\/span>\u00a0<\/span><\/p>\n

Also update explicit <\/span>AT TIME ZONE<\/span> references where appropriate. Installing the update does not rewrite application SQL or make the existing shared US-and-Canada identifier equivalent to the new province-specific definition.<\/span>\u00a0<\/span><\/p>\n

SQL Server on Linux<\/span><\/b>\u00a0<\/span><\/p>\n

Follow <\/span>Configure the time zone for SQL Server on Linux<\/span><\/a> for SQL Server 2022 or later. SQL Server on Linux map the Linux\/IANA time zone to a Windows identifier used internally by T-SQL.<\/span>\u00a0<\/span><\/p>\n

The documented mappings for the interim choices are:<\/span>\u00a0<\/span><\/p>\n\n\n\n\n\n\n
Affected region<\/span><\/b>\u00a0<\/span><\/td>\nLinux\/IANA identifier<\/span><\/b>\u00a0<\/span><\/td>\nSQL time zone identifier<\/span><\/b>\u00a0<\/span><\/td>\n<\/tr>\n
Most of BC<\/span>\u00a0<\/span><\/td>\nAmerica\/Whitehorse<\/span>\u00a0<\/span><\/td>\nYukon Standard Time<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Alberta and aligned locations<\/span>\u00a0<\/span><\/td>\nAmerica\/Regina<\/span>\u00a0<\/span><\/td>\nCanada Central Standard Time<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Manitoba<\/span>\u00a0<\/span><\/td>\nAmerica\/Cancun<\/span>\u00a0<\/span><\/td>\nEastern Standard Time (Mexico)<\/span>\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Configure the matching IANA zone in the SQL Server service or container\u2019s <\/span>TZ<\/span> environment, or through the applicable host configuration. Ensure the setting reaches the <\/span>SQL Server process<\/span><\/b>, not only an interactive shell; restart or redeploy that process as appropriate. <\/span>TZ<\/span> takes precedence over <\/span>\/etc\/localtime<\/span> and the other documented configuration sources.<\/span>\u00a0<\/span><\/p>\n

Do not assume that updating Linux <\/span>tzdata<\/span> alone updates SQL Server\u2019s Windows-zone definitions or mapping. For older releases, use the corresponding <\/span>SQL Server 2019<\/span><\/a> or <\/span>SQL Server 2017<\/span><\/a> documentation.<\/span>\u00a0<\/span><\/p>\n

Azure SQL Database<\/span><\/b>\u00a0<\/span><\/p>\n

As described in <\/span>my earlier announcement of local time zone support<\/span><\/a>, the public-preview feature allows configuration at the <\/span>database or session level<\/span><\/b>.<\/span>\u00a0<\/span><\/p>\n

For example, use the following options for Manitoba:<\/span>\u00a0<\/span><\/p>\n

-- Persistent database default\r\nALTER DATABASE SCOPED CONFIGURATION\r\nSET TIME_ZONE = 'Eastern Standard Time (Mexico)';\r\n\r\n-- Alternatively, override just the current connection\r\nSET TIME ZONE 'Eastern Standard Time (Mexico)';\u00a0\u00a0<\/code><\/pre>\n
A session override takes precedence over the database setting. <\/span>SET TIME ZONE LOCAL<\/span> removes the session override.<\/span>\u00a0<\/span><\/p>\n
Inside a stored procedure or dynamic SQL batch, the change is scoped to that execution. A normal <\/span>GO<\/span> batch separator does <\/span>not<\/span><\/b> reset a session setting. See the <\/span>SET TIME ZONE documentation<\/span><\/a> for scope and usage details.<\/span>\u00a0<\/span><\/p>\n
The setting affects current-time functions such as <\/span>GETDATE()<\/span>, <\/span>SYSDATETIME()<\/span>, and <\/span>SYSDATETIMEOFFSET()<\/span>. It does <\/span>not<\/span><\/b> convert stored values, change explicit <\/span>AT TIME ZONE<\/span> expressions, or change UTC timestamps in system views.<\/span>\u00a0<\/span><\/p>\n
Once the regional identifier becomes available, replace the interim setting at the scope your application uses. <\/span>SET TIME ZONE<\/span> is not supported on SQL Server.<\/span>\u00a0<\/span><\/p>\n
Azure SQL Managed Instance<\/span><\/b>\u00a0<\/span><\/p>\n
The <\/span>instance time zone can only be selected during creation<\/span><\/a>. To change the instance-level time zone itself, create a replacement instance with the required temporary or final time zone and migrate the workload.<\/span>\u00a0<\/span><\/p>\n
On SQL Managed Instances using the <\/span>Always-up-to-date update policy<\/span><\/a> where local time zone support is available, use <\/span>ALTER DATABASE SCOPED CONFIGURATION SET TIME_ZONE<\/span> or <\/span>SET TIME ZONE<\/span> to apply the same interim time zones at database or session scope. These settings change the effective time zone for supported current-time functions without migrating the instance. They do not change the instance-level time zone or SQL Agent schedules; an instance-wide time zone change still requires the migration approach below.<\/span>\u00a0<\/span><\/p>\n
\u00a0<\/span><\/p>\n\n\n\n\n\n
Migration option<\/span><\/b>\u00a0<\/span><\/td>\nHow it works<\/span><\/b>\u00a0<\/span><\/td>\nTrade-off and requirements<\/span><\/b>\u00a0<\/span><\/td>\n<\/tr>\n
Failover group<\/span><\/a>\u00a0<\/span><\/td>\nReplicate continuously, then perform a controlled planned failover after synchronization.<\/span>\u00a0<\/span><\/td>\nMore setup; generally lower cutover downtime. Instances must be in different regions and share a DNS zone.<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
Cross-instance point-in-time restore<\/span><\/a>\u00a0<\/span><\/td>\nRestore databases to a replacement instance in the same region, then cut applications over.<\/span>\u00a0<\/span><\/td>\nSimpler; generally longer downtime. Coordinate source writes and the final restore point to avoid omitting later transactions. Restore-point timestamps are interpreted as UTC.<\/span>\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Recreate instance-level dependencies, including logins, objects in <\/span>master<\/span>, SQL Agent jobs, credentials, linked servers, certificates, and server-level configuration. Validate applications and job schedules before retiring the old instance.<\/span>\u00a0<\/span><\/p>\n
Plan for two migrations when using an interim time zone<\/span><\/b>\u00a0<\/span><\/p>\n
If the final regional zone is unavailable, first migrate to an instance configured with the interim zone. After the regional zone becomes available, migrate again to another instance created with that final zone.<\/span>\u00a0<\/span><\/p>\n
For a failover-group approach that returns to the original region:<\/span>\u00a0<\/span><\/p>\n
Original MI \u2014 Region 1 \u2192 Temporary-zone MI \u2014 Region 2 \u2192 Final-zone MI \u2014 Region 1<\/span><\/b>\u00a0<\/span><\/p>\n
The service update <\/span>does not change the selected time zone of the existing temporary instance<\/span><\/b>. Budget for both migrations and their cutovers.<\/span>\u00a0<\/span><\/p>\n
Normally, failover-group partners should use matching time zones. A deliberate mismatch for this migration requires careful validation; it is not the recommended steady-state high-availability configuration.<\/span>\u00a0<\/span><\/p>\n
If only a query or display requires adjustment, an explicit conversion can avoid changing instance-local time:<\/span>\u00a0<\/span><\/p>\n
SELECT SYSUTCDATETIME() AT TIME ZONE 'UTC'\r\n\u00a0\u00a0\u00a0 AT TIME ZONE 'Eastern Standard Time (Mexico)' AS ManitobaLocalTime;\u00a0\u00a0<\/code><\/pre>\n
 <\/p>\n
This changes the query result\u2014not SQL Agent schedules or the instance\u2019s <\/span>GETDATE()<\/span> behavior.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
Affected locations in British Columbia, Alberta, and Manitoba will not turn their clocks back at 02:00 local time on November 1, 2026. They will remain at UTC\u221207:00, UTC\u221206:00, and UTC\u221205:00, respectively.\u00a0 Microsoft\u2019s interim guidance for British Columbia, Alberta, and Manitoba describes the new Windows time zones and temporary workarounds.\u00a0 SQL Server on Windows requires the […]<\/p>\n","protected":false},"author":92817,"featured_media":81,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,656,572,619],"tags":[510,636,726,552,34],"class_list":["post-7808","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure-sql","category-fabric-sql-database","category-managed-instance","category-t-sql","tag-azure-sql-database","tag-azure-sql-managed-instance","tag-fabric-sql","tag-sql-server","tag-t-sql"],"acf":[],"blog_post_summary":"
Affected locations in British Columbia, Alberta, and Manitoba will not turn their clocks back at 02:00 local time on November 1, 2026. They will remain at UTC\u221207:00, UTC\u221206:00, and UTC\u221205:00, respectively.\u00a0 Microsoft\u2019s interim guidance for British Columbia, Alberta, and Manitoba describes the new Windows time zones and temporary workarounds.\u00a0 SQL Server on Windows requires the […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts\/7808","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/users\/92817"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/comments?post=7808"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts\/7808\/revisions"}],"predecessor-version":[{"id":7811,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/posts\/7808\/revisions\/7811"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/media\/81"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/media?parent=7808"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/categories?post=7808"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-json\/wp\/v2\/tags?post=7808"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}