Claude c169c419c3 fix(timer): correct count-to-end expected end across modes and days ...

The first pass pinned the count-to-end end with
`Math.max(expectedStart, plannedEnd)`, but those operands live in
different coordinate spaces: `getExpectedStart` bakes in the day shift,
the relative-start shift and the live runtime offset, while `plannedEnd`
was raw time-of-day. The result was only correct in single-day Absolute
mode and drifted in Relative mode and across day boundaries.

A count-to-end event is anchored to its fixed wall-clock end, so its
expected end is the scheduled end normalised for the day, with no runtime
offset and no relative-start shift (matching getExpectedFinish, which
returns the raw timeEnd). Compute it directly as
`normalisedTimeStart + duration`.

Add relative-mode and multi-day unit tests covering the cases the
previous formula got wrong.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACGuFWt5aN7Fv3AkYXgxLm

2026-06-21 08:07:33 +00:00

..

src

fix(timer): correct count-to-end expected end across modes and days

2026-06-21 08:07:33 +00:00

.oxlintrc.json

Deps migration (#1988)

2026-03-08 16:22:12 +01:00

index.ts

fix(timer): count-to-end events absorb overtime in expected end times

2026-06-20 06:44:06 +00:00

package.json

Deps migration (#1988)

2026-03-08 16:22:12 +01:00

tsconfig.app.json

Deps migration (#1988)

2026-03-08 16:22:12 +01:00

tsconfig.json

Deps migration (#1988)

2026-03-08 16:22:12 +01:00

tsconfig.vitest.json

Deps migration (#1988)

2026-03-08 16:22:12 +01:00

vite.config.ts

v2 (#386)

2023-05-18 14:02:22 +02:00