Skip to content

parse_time computes elapsed hour durations incorrectly across DST transitions #377

Description

@Calmingstorm

Confirmed elapsed-time error across DST

Reviewed master at 886c36d8ebe861aa987059a1744d45b78797baae (v4.7.0). Suggested priority: P2.

parse_time adds a timedelta directly to a datetime carrying the configured ZoneInfo timezone. Across a daylight-saving transition this is wall-clock arithmetic, not the requested elapsed duration.

Reproduction

now = datetime(2026, 3, 7, 12, 0, tzinfo=ZoneInfo("America/New_York"))
result = datetime.fromisoformat(parse_time("in 24 hours", now=now))
elapsed = (result.astimezone(UTC) - now.astimezone(UTC)).total_seconds()
result: 2026-03-08T12:00:00-04:00
elapsed_seconds: 82800  (23 hours)
expected_seconds: 86400 (24 hours)

Independently reproduced twice. Users in a DST-observing configured timezone can get a reminder or operation an hour early/late.

Acceptance criteria

  • Use elapsed-time arithmetic for seconds/minutes/hours, converting through UTC if needed before serializing in the configured timezone.
  • Test spring-forward and fall-back transitions by comparing UTC instants, not same-zone datetime subtraction.
  • Preserve calendar/wall-clock semantics for tomorrow at ... and cron.
  • Explicitly decide day/week wording separately rather than accidentally changing calendar expectations.

Behavior change: elapsed-duration requests around offset transitions become accurate. This is not a request to change cron timezone semantics. No source changes were made.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions