Known Issue: FME Flow Schedules Run Late After Canadian Time Change

Issue

If the machine running FME Flow is in British Columbia, Alberta, the Northwest Territories, or Manitoba and you change nothing, then from 2:00 a.m. on November 1, 2026, schedules set for a time of day run one hour late, and times in FME Flow log files are one hour behind the clock. For example, a 9:00 a.m. schedule runs at 10:00 a.m. A fix is expected in FME Flow 2026.4.

Am I Affected?

You are affected if all of these are true:

• You run self-managed FME Flow 2026.3 or earlier on Windows or Linux.
• The machine running FME Flow is in one of the four provinces or territories, whether or not it has already been switched to the new Windows time zone.
• The machine uses one of these time zones:
  • Windows: (UTC-08:00) Pacific Time (US & Canada), (UTC-07:00) Mountain Time (US & Canada), or (UTC-06:00) Central Time (US & Canada); or already one of the new zones in the table below; or one of Microsoft's temporary zones for machines that cannot install the update before November 1 (as of October 8, 2026; Microsoft's interim guidance for British Columbia, Alberta, Manitoba): (UTC-07:00) Yukon, (UTC-06:00) Saskatchewan, or (UTC-05:00) Eastern Time (US & Canada) with Adjust for daylight saving time automatically turned off.
  • Linux: a zone from the Linux zone (B or C) row in the table below; a US zone that keeps falling back (America/Los_Angeles, PST8PDT, America/Denver, MST7MDT, America/Chicago, CST6CDT); or already an Etc/GMT zone.
• You use Basic schedules, CRON schedules, or Repeat-on-Interval schedules measured in days, weeks, months, or years; Automations with a Schedule trigger; or queue control active periods.

You are not affected if you use FME Flow Hosted, or if the machine running FME Flow is set to UTC or to a time zone outside the four provinces and territories (unless it is one of Microsoft's temporary zones above). Schedules that repeat every N seconds, minutes, or hours, job queue timeouts and time-to-live settings, and login session timeouts are not affected. For Docker and Kubernetes, see Docker and Kubernetes below.

Cause

British Columbia, Alberta, the Northwest Territories, and Manitoba will not fall back on November 1, 2026. Their clocks stay on summer time all year: British Columbia at UTC-7, Alberta and the Northwest Territories at UTC-6, and Manitoba at UTC-5.

FME Flow carries its own copy of the world's time zone rules, separate from the operating system. In every FME Flow release up to and including 2026.3, that copy still expects these provinces to fall back on November 1. Updating Windows or Linux does not fix this on its own.

Files

OpenJDK21U-jdk-sources_21.0.13_9.tar.gz (115.2 MB)

Workaround

Until a fix is available or you are able to upgrade, apply the steps below on every machine running FME Flow: Core, Web, and every machine that runs FME Flow Engines. It is safe to apply them now: the old and new rules agree until 2:00 a.m. on November 1. Applying them before November 1 avoids late jobs and incorrect job history.

Your Region's Values

1. Apply the Fix for Your Platform

Windows

A1 is required on every Windows machine. A2 is required on some machines and optional on the rest; step 3 shows which.

A1. Install the Windows update that adds the new time zone for your Windows version (British Columbia, Alberta, Manitoba), then select your province's zone from the table in Date & Time settings. Installing the update does not select the zone for you.

A2. Required if the quick test in step 3 shows 0x1, or if the step 3 log line shows anything other than the exact fixed offset for your province. Stop FME Flow. In <FME Flow install dir>\Utilities\jre\lib, replace tzdb.dat with the file attached to this article (keep a copy of the original and of tzmappings). Then add the three new Windows time zone lines to tzmappings in an elevated PowerShell. Copy the lines exactly: if any line in tzmappings is malformed, Java rejects the whole file.

Provided as is, without warranty; test before production use.

Add-Content -Encoding ASCII "<FME Flow install dir>\Utilities\jre\lib\tzmappings" @("British Columbia Standard Time:001:America/Vancouver:", "Alberta Standard Time:001:America/Edmonton:", "Manitoba Standard Time:001:America/Winnipeg:")

Add all three lines whichever province you are in. Always replace tzdb.dat as well: with the original tzdb.dat, the new tzmappings lines make schedules run 1 hour late from November 1.

Linux

Do one of these:

• B. Update FME Flow's time zone rules (recommended): stop FME Flow, replace <FME Flow install dir>/Utilities/jre/lib/tzdb.dat with the file in the Files section of this article (keep a copy of the original), and make sure the machine uses the Linux zone from the table.
• C. Update FME Flow's Java runtime to the October 2026 Java update (17.0.21 or 21.0.13 or later), staying on the same Java version family that FME Flow shipped with. Download it from Adoptium (Eclipse Temurin). Do not use Oracle builds or Oracle's time zone updater tool (TZUpdater). This option has not yet been fully tested by Safe Software.
• D. Switch the machine to the fixed-offset zone from the table, for example sudo timedatectl set-timezone Etc/GMT+7 in British Columbia. This changes the time zone of the whole machine, and job history from previous winters displays one hour off.

Updating the operating system's tzdata package is also a good idea for the rest of the system, but FME Flow does not use it.

2. Restart FME Flow

Restart all FME Flow services on every machine. FME Flow reads the time zone only when it starts. Then reload any FME Flow browser tabs that were open before the restart.

3. Check the Time Zone FME Flow Is Using

Quick test (Windows only). In a Command Prompt, run:

reg query HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal

If the value is 0x1, A2 is required on this machine.

Log check (all platforms). Open fmeprocessmonitorcore.log (Resources > Logs > core > current in the Web UI) and find the Default time zone line written at startup. It must exactly match the Step 3 value for your option in the table. Do not go on to step 4 until it does.

4. Refresh Your Schedules

FME Flow works out each schedule's next run time in advance, and a restart does not recalculate it. To refresh a schedule, disable it and enable it again (saving it also works). To refresh an Automation, stop it and start it.

Never needs refreshing: schedules that repeat in seconds, minutes, or hours; queue control active periods (correct after the restart); and disabled schedules and stopped Automations, which pick up the fix when you next enable or start them. The exception is a disabled one-time or Repeat-on-Interval schedule with a start date after November 1: check its start time when you enable it.

If you have many schedules and Automations, you can refresh them with the FME Flow REST API.

Docker and Kubernetes

No action is needed unless you set TZ for FME Flow containers. If you did, contact Support. Do not remove TZ on an existing deployment: the containers then run in UTC, which re-reads every stored time.

Resolution

This issue has a workaround. FME Flow 2026.4 is expected to be the first release with the new rules built in. The upcoming FME hotfix does not include FME Flow scheduling changes. Re-apply the workaround after any FME Flow update earlier than 2026.4.

Related Issues

• See Known Issue: Date/Time Transformers Do Not Recognize New Canadian Time Zones
• FME Flow Hosted: users are unable to select the new time zones in account settings. (FLOWHOSTED-2847)

Additional Resources

• FME Flow: About Times and Time Zones
• Microsoft: British Columbia 2026 time zone update available now
• Microsoft: Alberta 2026 time zone update available now
• Microsoft: Manitoba 2026 time zone update available now

Data Attribution

Eclipse Temurin and Eclipse Adoptium are trademarks of Eclipse Foundation AISBL. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.