This repository was archived by the owner on Oct 1, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 1, 2026. It is now read-only.
Make schedule time-zone behavior explicit and deterministic #33
Description
Activity
Proposed abstraction and compatibility plan:
- resolve TimeZoneInfo.Local once at startup and register that concrete TimeZoneInfo as the application-wide recurring-schedule zone alongside the existing TimeProvider
- inject both dependencies into CaptureScheduleService and Sessions/Create, removing direct DateTime.Now / TimeZoneInfo.Local reads
- centralize wall-time conversion: invalid spring-forward values advance minute-by-minute through the gap; ambiguous one-time starts choose the larger offset (earlier UTC instant)
- evaluate recurring daily/weekly membership in wall-clock time so both repeated-hour UTC instants map inside matching bounds; keep persisted one-time starts untouched as UTC
- expose a shared zone label with the offset computed at TimeProvider.GetUtcNow() on New session and System check
- use custom deterministic DST rules in tests for spring gap, fall ambiguity, repeated-hour membership, overnight windows, and UTC
- document TZ startup/restart semantics for containers and preserve all existing JSON fields.
Completed by contributor PR #50 through integration #59, followed by the fall-back interval correction in #61. The exact corrective head passed 176 solution tests and all six PR checks; final main 1de55dc passed CI, CodeQL, Container, and dependency submission. Rechecked the issue acceptance criteria: injected startup zone and TimeProvider, rendered zone/offset on both pages, deterministic DST/overnight/UTC tests, UTC one-time starts, and TZ/restart documentation. Closing after checking the current issue state.
Goal
Daily and weekly capture windows use the host's local time zone. Containers commonly default to UTC, but the UI does not identify the active zone and tests cannot select one explicitly.
Required time-zone policy
TZrequires restart and changes future recurring evaluations, not stored one-time starts.Acceptance criteria
TimeProvider.GetUtcNow().CaptureScheduleServicereceives an explicitTimeZoneInfodependency rather than readingTimeZoneInfo.Localdirectly.CaptureScheduleServiceand Sessions/Create use the same injected time zone for local-to-UTC conversion and the sameTimeProviderfor future validation instead ofDateTime.Now.TimeZoneInfo; they never depend on the CI host's local zone.TZ, what happens when it is omitted, and the restart behavior.Please comment with your proposed time-zone abstraction and compatibility plan before starting. A draft PR is welcome.