Fix: Load ICU 2026e tz data so Canadian schedules stay on time by adishM98 · Pull Request #18507 · ToolJet/ToolJet · GitHub
Skip to content

Fix: Load ICU 2026e tz data so Canadian schedules stay on time - #18507

Merged
adishM98 merged 2 commits into
lts-3.16from
fix/icu-tz-2026e-override
Oct 21, 2026
Merged

Fix: Load ICU 2026e tz data so Canadian schedules stay on time#18507
adishM98 merged 2 commits into
lts-3.16from
fix/icu-tz-2026e-override

Conversation

@adishM98

@adishM98 adishM98 commented Oct 21, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

📝 What this does

Our images bundle Node 22.15.1, which carries tz 2025a, so workflow schedules in Vancouver, Edmonton, Inuvik and Winnipeg fire an hour late from 1 Nov 2026, when BC, Alberta, Manitoba and the NWT stop falling back.

This loads ICU 2026e time-zone data on top of Node's bundled data in every runtime image and the EC2 AMI, without a risky Node bump. Same change for main: #18508.

🔀 Changes

  • Added the four ICU 2026e time-zone files from unicode-org/icu-data
  • Pointed Node at them via ICU_TIMEZONE_FILES_DIR in all 10 runtime Dockerfiles and the EC2 AMI's systemd unit
  • Added a build-time check that fails the image or AMI build if stale tz data is still loaded
🛡️ Merge impact: 🟢 reversible
  • Reach: CE, EE and Cloud images (LTS and pre-release), ee-try-tooljet* through their base image, and the EC2 AMI. Only time-zone offsets change, and only for zones with rule changes after 2025a.
  • Not included: a Node bump. 2026e isn't in a released Node 22 yet (nodejs/Release#1185), and 22.15 → 22.24 is too big to test before 1 Nov. Remove the override when Node ships tz ≥ 2026e; the build check keeps passing after the bump.
  • Not included: schedules whose next run was queued before this ships keep the old offset for that one run.

🏗️ Architecture

flowchart LR
  A[Workflow schedule<br/>pattern + tz] --> B[BullMQ job scheduler]
  B --> C[Intl / ICU zone rules]
  C -- built-in tz 2025a --> D[09:00 local fires at 10:00]
  C -- ICU_TIMEZONE_FILES_DIR 2026e --> E[09:00 local fires at 09:00]
Loading

🧪 How to test

  • Run BullMQ's getNextMillis('0 9 * * *') for the four zones on Node 22.15.1, with and without the override
  • Build a linux/amd64 node:22.15.1-bookworm image with the override block
  • Confirm the build check fails on tz 2025a
  • Build the LTS EE production image in CI (manual Docker build) and run node -p process.versions.tz in it (2026e)
  • Build the AMI and check systemctl show nest -p Environment includes ICU_TIMEZONE_FILES_DIR
  • Schedule a 0 9 * * * workflow in America/Winnipeg on that image, and confirm the first run after 1 Nov is 14:00Z (clock faked; not yet seen firing on 1 Nov)
🧾 Evidence

  • Before: BullMQ 5.77.6, Node 22.15.1, first run after 2026-12-14T00:00Z: Vancouver 17:00Z, Edmonton 16:00Z, Inuvik 16:00Z, Winnipeg 15:00Z (all one hour late)

  • After: same call with the override in a linux/amd64 container: Vancouver 16:00Z, Edmonton 15:00Z, Inuvik 15:00Z, Winnipeg 14:00Z. October results unchanged.

  • CI image: manual Docker build run 39557631270 built ee-production.Dockerfile at f01a402649; the tz check step ran and passed. The follow-up commit only changes the comment in this file.

  • Real schedule on that image: a 0 9 * * * schedule in America/Winnipeg created through the API is stored in Redis with pattern 0 9 * * * and tz America/Winnipeg, next run 2026-10-21T14:00Z (09:00 CDT). In the container, Node reports tz=2026e and ICU_TIMEZONE_FILES_DIR=/usr/local/share/icu-tz.

  • After 1 Nov, clock faked: the same upsertJobScheduler({ pattern, tz }) call, using the image's own BullMQ and Redis on a throwaway queue:

    Clock (just after a run) With override Override removed
    2026-10-14 10-15 14:00Z 10-15 14:00Z
    2026-10-31 (last run before the change) 11-01 14:00Z 11-01 15:00Z
    2026-12-14 12-14 14:00Z 12-14 15:00Z

  • Build check without override: Error: stale tz data: 2025a, exit 1

  • File sha256 (unicode-org/icu-data tzdata/icunew/2026e/44/le):
    5b484c7f02c99d5164208ce84e18fba67c6314d77cf60503e2b19f708b66c6da metaZones.res
    5e77ce5afb7374a36cbe3be197d0a6deaa919e6f672c2a372f7a9d91b7f8534f timezoneTypes.res
    b8c3a7adb94fd659f8203ee4af4dc72a4e6b14566baac1855c493096f337184b windowsZones.res
    5a168fb78cccfc872f9a50e91facf0bf8b7204a6c4f92fe5c64a8165e9e62448 zoneinfo64.res

@adishM98 @claude
Fix: Override bundled Node tz data with ICU 2026e in images
f01a402 
Node 22.15.1 ships tz 2025a, so BullMQ workflow schedules in Vancouver,
Edmonton, Inuvik and Winnipeg fire an hour late from 1 Nov 2026. Load
ICU 2026e zone files via ICU_TIMEZONE_FILES_DIR and fail the build if
stale tz data is still active.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@adishM98
adishM98 requested a review from slancerk as a code owner October 21, 2026 06:46
@github-actions

github-actions Bot commented Oct 21, 2026

Copy link
Copy Markdown
Contributor

@adishM98 @claude
Fix: Apply ICU 2026e tz override to EC2 AMI and trim comments
1520ced 
The AMI installs Node via nvm and runs the server under systemd, so it
never saw the Dockerfile override. Copy the vendored zone files during
the AMI build, set ICU_TIMEZONE_FILES_DIR in nest.service, and fail the
build on stale tz data.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@adishM98 adishM98 mentioned this pull request Oct 21, 2026
Merged
6 tasks done
@adishM98 adishM98 changed the title Fix: Load ICU 2026e tz data in images for Canadian DST change Fix: Load ICU 2026e tz data so Canadian schedules stay on time Oct 21, 2026
@adishM98
adishM98 merged commit 3929680 into lts-3.16 Oct 21, 2026
22 checks passed
@adishM98
adishM98 deleted the fix/icu-tz-2026e-override branch October 21, 2026 08:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@akshaysasidrn akshaysasidrn akshaysasidrn approved these changes
@slancerk slancerk Awaiting requested review from slancerk slancerk is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@adishM98 @akshaysasidrn