Repository navigation
Fix: Pin the date in schedule tests so they pass on both sides of DST - #780
Merged
Merged
Conversation
A legacy UTC schedule clock carries no offset, so the write path and the startup migration resolve it against today's: 02:30Z is 19:30 under PDT but 18:30 under PST. Five tests hard-coded the summer answer and started failing when DST ended on 2026-11-01. The tests now pin "today" to a summer date in the two modules that do the conversion, and two new winter-pinned tests cover the PST half of the year. No application code changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Five tests in
backend/tests/test_campaign_schedule.pystarted failing on 2026-11-01, when DST ended. Each one failed with'18:30' == '19:30'.A legacy UTC schedule clock carries no offset, so the write path (
_utc_clock_to_local) and the startup migration (_migrate_schedule_times_to_local) both resolve it against today's offset. That's by design: 02:30Z is 19:30 under PDT but 18:30 under PST. The tests hard-coded the summer answer, so they only passed for half the year.Changes
_pin_todayhelper patchesdatetime.date.today()only inbackend.models.dbandbackend.routers.campaigns.schedule, never globally.TestLocalTimeModel,TestScheduleTimeMigration,TestStaleBundleRepair) are pinned to a July date with asummer_todayfixture.TestLegacyClockFollowsTodaysOffsetpins a January date and asserts 18:30, covering the PST half on both the write path and the migration.No application code changes.
Testing
mainbefore the fix: 5 failed, 8548 passed. These were the only failures.-n 4 --dist loadgroup.ruff check backend/andmypy backend/are clean. The frontend suite was already green (7053 passed).🤖 Generated with Claude Code