[xcompass]

Why

BC stays on UTC-7 permanently: no fall back on Sunday 2026-11-01 02:00. WeBWorK converts course dates with Perl DateTime::TimeZone, which ships its own compiled zone data and ignores /usr/share/zoneinfo.

The image's copy is Ubuntu 24.04's libdatetime-timezone-perl 1:2.62-1+2024a (Olson 2024a), and noble will not get a newer one. So from Nov 1, for any date between 2026-11-01 and 2027-03-14:

• Every server-rendered date shows 1 hour early, labelled "PST", e.g. a 23:59 deadline shows as "10:59:00 PM PST".
• Server-side parsing (set-definition import, default due dates) stores dates 1 hour late.

Grade passback, queues and LTI tokens use epochs or GMT and are not affected.

Change

Dockerfile-prod, plus Dockerfile to keep them in step:

• Phase 4 now runs cpanm install -n DateTime::TimeZone@2.71 (Olson 2026d). 2.68 is the first release with the BC change. The module installs to /usr/local/share/perl/5.38.2, which comes before the apt copy in @INC.
• A build check fails the image if America/Vancouver is not UTC-7 on 2026-12-01.

Testing

Tested in lthub/webwork:v2.20.8 (the current prod image) using WeBWorK's own WeBWorK::Utils::DateTime:

	2.62 (now)	2.71
display 2026-12-01 23:59 BC (epoch 1796194740)	December 1, 2026, 10:59:00 PM PST	December 1, 2026, 11:59:00 PM MST
parseDateTime("12/01/2026 at 11:59pm")	1796198340 (wrong)	1796194740
summer 2026	PDT	PDT (unchanged)
Dec 2025	PST	PST (unchanged)
build check	exit 1	exit 0

cpanm installed only DateTime-TimeZone; the image already had all its dependencies.

Notes

• After this, server-rendered winter dates say "MST" (tzdata's label for BC's permanent -07). BC's official abbreviation is "PCT", which no tz release uses yet.
• Due dates already stored from an old-rules conversion will show 1 hour late, e.g. 12:59 AM. These need a one-off data review after deploy.
• Deploy plan: tag v2.20.9, pin it in configuration, deploy staging, then prod under a CHG before 2026-10-31.