Broque Thomas 3e61105a1d Close three review gaps before PR 1 ships ... Self-review pass on ec4a55c1 — applying the standing kettui-grade rule (see memory/feedback_always_build_kettui_grade.md). Three issues that would have surfaced on review: 1. Silent tz fallback to UTC ``_resolve_tz`` returned UTC when the IANA name was unknown — no log, no warning. User on a host without ``tzdata`` who configures ``America/Los_Angeles`` got schedules running silently at UTC offset with no way to debug. Now logs WARNING once per unknown name (deduped via ``_UNKNOWN_TZ_WARNED`` set so a misconfigured row doesn't spam every poll cycle) and the log line names BOTH real causes — typo or missing tzdata — so the user can fix from a single grep. 2. ``weeks`` unit drift from engine I added ``'weeks': 86400*7`` to ``_INTERVAL_MULTIPLIERS`` but the engine's existing ``_calc_delay_seconds`` only recognises minutes/hours/days. Until PR 2 collapses both paths through this function, any row whose config snuck through with ``unit='weeks'`` would get scheduled by the engine as 1-hour and by this function as 7-day — drift between two live implementations. Dropped ``weeks`` from the map to match the engine. Added a comment pinning the map to the engine's contract and a regression test that asserts ``unit='weeks'`` falls back to the same hours default the engine produces. 3. DST edge cases unverified The module docstring claims DST-aware via ``zoneinfo`` but no test pinned the spring-forward gap (02:30 LA on DST-Sunday doesn't exist) or fall-back ambiguity (01:30 LA on fall-Sunday happens twice). Three new tests: - ``test_dst_spring_forward_lands_after_the_gap`` — pins that the function doesn't crash + lands on a real instant past ``now``. - ``test_dst_fall_back_handles_ambiguous_local_time`` — pins zoneinfo's default-earlier-instant resolution for ambiguous local times (01:30 PDT vs 01:30 PST → picks PDT). - ``test_weekly_across_dst_boundary_keeps_local_wall_clock`` — pins that a "every Sunday at 09:00 LA" schedule keeps the local wall clock across the boundary even though the UTC equivalent shifts by an hour. This is the exact bug class that caused the May 2026 "next in 8h" tz mismatch. Also loosened ``tzdata==2026.2`` to ``tzdata>=2024.1``. IANA tz data changes a few times a year for real-world DST policy updates; pinning to one snapshot would freeze the app's tz knowledge to the build date and miss future government-mandated rule changes. 41 schedule tests pass (5 new); 240 across the full automation suite. Ruff clean.		2026-05-27 11:33:05 -07:00
..
handlers	Fold provider-matching into PlaylistSource contract (Phase 1b)	2026-05-26 13:07:01 -07:00
__init__.py	Extract automation handlers (1/N): infrastructure + 3 simple handlers	2026-05-15 10:25:41 -07:00
api.py	Add owned_by column for Auto-Sync schedule ownership	2026-05-24 23:40:22 -07:00
blocks.py	Personalized playlist pipeline: auto-sync discover-page playlists	2026-05-15 18:41:08 -07:00
deps.py	Refactor refresh_mirrored to use unified PlaylistSource registry	2026-05-26 12:52:39 -07:00
progress.py	Surface silent exceptions across remaining modules — ~70 sites	2026-05-07 10:28:58 -07:00
schedule.py	Close three review gaps before PR 1 ships	2026-05-27 11:33:05 -07:00
signals.py	Add module logger + surface silent exceptions in 7 logger-less files — 12 sites	2026-05-07 10:27:04 -07:00