fix(planning): plan TIME_WINDOW rules on the picked calendar dates #315

Merged

nessar merged 1 commits from feature/311-time-window-local-dates into develop 2026-10-19 15:40:14 +02:00

Conversation 0 Commits 1 Files Changed 2

+39 -3

nessar commented 2026-10-19 15:23:40 +02:00

Owner

Copy link

Copy source

Summary

• TIME_WINDOW rule dates reached the planner as local-midnight Date objects, and the planner read their Europe/Paris date, so in time zones ahead of Paris every window started and ended one day early.
• PlanningCalculationService.request now formats startDate and endDate as YYYY-MM-DD from local components, as balance dates already are. Other rule types pass through unchanged.

Tests

• New case in planning-calculation.service.spec.ts, run in Pacific/Auckland: fails before the fix (the planner received the instant 2026-12-19T11:00Z), passes after. It also fails if the dates are converted to their Paris date instead.
• Full suite 765/765, typecheck, prettier and eslint clean at base 9e5c93e.
• Real-planner probes in Auckland, Tokyo and Kiritimati: before the fix the window moved to the previous Sunday and planning conflicted; after it the leave lands on the picked date, including after a save and reload. New York, Paris and UTC were unaffected either way.

Known limit

A device that changes time zone between saving and planning can still read a saved rule as another date (noted in the issue).

Closes #311

🤖 Generated with Claude Code

## Summary - TIME_WINDOW rule dates reached the planner as local-midnight `Date` objects, and the planner read their Europe/Paris date, so in time zones ahead of Paris every window started and ended one day early. - `PlanningCalculationService.request` now formats `startDate` and `endDate` as `YYYY-MM-DD` from local components, as balance dates already are. Other rule types pass through unchanged. ## Tests - New case in `planning-calculation.service.spec.ts`, run in `Pacific/Auckland`: fails before the fix (the planner received the instant `2026-12-19T11:00Z`), passes after. It also fails if the dates are converted to their Paris date instead. - Full suite 765/765, typecheck, prettier and eslint clean at base `9e5c93e`. - Real-planner probes in Auckland, Tokyo and Kiritimati: before the fix the window moved to the previous Sunday and planning conflicted; after it the leave lands on the picked date, including after a save and reload. New York, Paris and UTC were unaffected either way. ## Known limit A device that changes time zone between saving and planning can still read a saved rule as another date (noted in the issue). Closes #311 🤖 Generated with [Claude Code](https://claude.com/claude-code)

nessar added 1 commit 2026-10-19 15:34:34 +02:00

fix(planning): plan TIME_WINDOW rules on the picked calendar dates ... bc5ee50bd5

Rule windows reached the planner as local-midnight Date objects, and the
planner read their Europe/Paris date, so east of Paris every window
started and ended one day early. Format them from local components as
YYYY-MM-DD before planning, as balances already are.

Closes #311

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

nessar force-pushed feature/311-time-window-local-dates from 0b8424503c to bc5ee50bd5 2026-10-19 15:34:34 +02:00 Compare

nessar merged commit bc5ee50bd5 into develop 2026-10-19 15:40:14 +02:00

nessar deleted branch feature/311-time-window-local-dates 2026-10-19 15:40:15 +02:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

blocked-on-bun-release

Cannot be acted on until a new Bun release ships

bug

dependencies

docker

documentation

duplicate

enhancement

github_actions

good first issue

help wanted

invalid

javascript

needs-info

needs-triage

question

ready-for-agent

wontfix

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

renovate (renovate) Bot nessar (nessar)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: nessar/vac-optimizer#315