Skip to content

fix(dates): keep a date on its own day where local midnight is skipped - #467

Open
ryanlewis wants to merge 2 commits into
mainfrom
claude/optimistic-johnson-ulijot
Open

ryanlewis wants to merge 2 commits into
mainfrom
claude/optimistic-johnson-ulijot

Conversation

@ryanlewis

Copy link
Copy Markdown
Owner

Symptom

In a timezone whose daylight-saving change skips local midnight (Santiago, Asunción, Havana, Beirut…), a to-do scheduled or due on that one day is shown a day early. In Santiago, a to-do dated 2026-09-06 prints as 2026-09-05 in plain output and --json. things --on 2026-09-06 also filters on the 5th, so it matches the wrong rows.

Cause

ThingsDate.ToTime and ParseListDate built time.Date(y, m, d, 0, 0, 0, 0, time.Local). When midnight doesn't exist, Go returns 23:00 on the previous day. ThingsDate.String and AddDays read the day back from that value, and --on/--from/--to re-encoded it.

Fix

Add model.DayStart, which steps forward to the first hour that is on the requested day. ToTime and ParseListDate use it. Normal days are unchanged and still resolve to midnight.

Tests

TestThingsDateSkippedMidnight and TestParseListDateSkippedMidnight pin the zone to America/Santiago. Both failed before the fix. go test -race ./... passes. make lint couldn't run in this environment (golangci-lint is built with Go 1.25, below the repo's 1.26.9), so only go vet and gofmt were checked. No command surface changed, so SKILL.md and docs are untouched.

Ran as part of a weekly bughunt routine.


Generated by Claude Code

@ryanlewis ryanlewis added fix Bug fix bughunt Found by the weekly bughunt routine labels Oct 24, 2026 — with Claude
Ports the toolchain bump from #464 so govulncheck (GO-2026-6809) passes.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VXBaAmufjWXbgKvVRnELU8

Copy link
Copy Markdown
Owner Author

The check job failed in govulncheck, not in tests or lint: GO-2026-6809 (crypto/x509), a Go 1.26.9 stdlib vulnerability fixed in 1.26.10. This diff doesn't touch it, and the same failure would hit main. #464 bumps the toolchain, so I ported that one-line go.mod change (toolchain go1.26.10) here in 54235e1. It will be a no-op once #464 merges.


Generated by Claude Code

This branch has not been deployed

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

Labels

bughunt Found by the weekly bughunt routine fix Bug fix

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants