Manitoba gave the tz project six weeks to propagate a permanent zone change

The failure is one hour, in one direction, and nothing logs it. A host still carrying pre-2026c rules will apply the old transition at 2:00 AM on 1 November 2026 and subtract an hour that those four jurisdictions no longer subtract ^[5]. Cron entries still fire. They fire an hour off local wall clock, and they keep doing it until the data is replaced. The politicians call it permanent daylight time ^[3]. In tz it is a new standard time: America/Vancouver becomes MST, Edmonton and Inuvik become CST, and Manitoba stays on UTC-5 all year ^[4].

Whether patching the host helps depends on where the process reads its rules. Go, Python's zoneinfo, .NET on Linux and Ruby's tzinfo all read the OS files, and so does anything in C, through glibc ^[13]. Node does not. It uses ICU compiled into the node binary and ignores /usr/share/zoneinfo entirely, so the fix there is installing a newer runtime ^[14]. On Linux the OS copy moves whenever someone runs a package update ^[16]; on the author's Mac, where Apple maintains the files, /usr/share/zoneinfo/+VERSION still read 2026c on 20 September ^[15].

Container images freeze on their build date, and slim bases such as Alpine ship no tzdata at all ^[17]. The dev.to author hit that directly, with cron images failing on unknown time zone America/New_York until he imported _ "time/tzdata" ^[18]. That works, and it moves the copy inside the binary, so the next correction arrives by rebuild instead of by package upgrade ^[7].

Postgres keeps its own copy in the source tree. Compile it with --with-system-tzdata=/usr/share/zoneinfo and it reads the OS files; compile it without, and it takes new rules from minor releases ^[19]. The 13 August minor release follows 2026c, which has British Columbia and Alberta ^[20]. The next one is dated 12 November, eleven days after the transition ^[3].

MySQL stores named zones as rows rather than files. America/Vancouver exists in a table in the mysql schema because someone ran mysql_tzinfo_to_sql /usr/share/zoneinfo, and that table holds whatever the OS held on the day it was loaded ^[21].

Releases that move future timestamps are ordinary: 26 of the 31 since 2020a did ^[8], about five in six ^[1]. Palestine accounts for seven, Morocco four, Fiji and Greenland three each, and nine are spread across places that appear once ^[9][2]. Mexico's end of DST observation shipped in 2022f, two days before it took effect ^[10]. Lebanon pushed its March 2023 start back a month and cancelled that five days later ^[11]. The dev.to post compared releases against the official announcements and found tz shipping the same day as the announcement most of the time ^[12], so the six weeks Manitoba allowed ^[6], roughly a twelfth of the year the project asks for ^[5][6], is spent downstream in distros, images and database builds.

For this to be your problem you need schedules, billing periods or reporting windows anchored to local wall time in one of the four. The author runs a Go scheduler that stores timestamps in UTC with a time zone field per customer ^[22], and wrote that "we don't have any customers in the affected regions so this doesn't quite affect me this time" ^[23]. UTC storage moves the question to read time. Whatever tzdata the process holds when it computes the next local fire time decides the answer.