[tkoehlerlg]

The 0.7.1 bug-fix batch: three wrong answers that ship today, the input validation that stops a
fourth from being possible, and the release checks that were not checking anything.

1. The daily window was measured on the wrong day

earliestTime/latestTime name a time of day for the caller. The filter took the slot's UTC
calendar date, built the window for that date in the target zone, and compared instants — so any
local day straddling UTC midnight was tested against the neighbouring day's window.

request	before	after
New York 09:00–22:00	10 slots, last at 18:00	13 slots, last at 21:00
Tokyo 02:00–06:00	0 slots	4
New York 20:00–24:00	10 of 15	all four evening hours

Every US customer silently lost their evenings. Reading the window from the instant on the caller's
clock also deleted the special case 24:00 needed.

2. An availability window is a set of instants, not two resolved endpoints

A weekly pattern names times on the host's clock. Resolving its two endpoints and taking everything
between them is a different thing, and the difference shows on the two days a year a zone changes
offset — in both directions:

• Offering time nobody gave: a New York 01:00–05:00 Sunday ran to 06:00 local on the
  spring-forward day; Berlin's started at 00:00.
• Losing time silently: an Auckland Saturday 09:00–17:00 ended at 16:00, on an ordinary
  Saturday that is not even the transition day, because the single-pass offset lookup landed on the
  afternoon before.

A window is now every instant whose local time falls inside it. A skipped wall time is simply absent
from that set, and a repeated one is present twice — so neither needs a disambiguation policy to
choose, configure or document. 09:00–17:00 stays eight hours on the clock, which is seven or nine
elapsed on a transition day, and is exactly what the same recurring block does in the host's own
calendar.

This is also the rule the library already obeyed where it was accidentally correct: the all-day
00:00–23:59 pattern already produced 23- and 25-hour days.

23:59 now names the end of the day in every zone. It already did everywhere except the literal
string 'UTC', which was left with a one-minute unavailable sliver that 'Etc/UTC' did not have.

3. The week advanced on the local calendar

getMonday built Monday 00:00 UTC while the walk advanced with setDate and the converter
validated with getDay. West of UTC the validator threw on every call with a pattern —
including the one docs/availability-scheduler.md recommends. East of it, spring-forward shifted
the entire pattern by a day until October.

4. Busy times that cannot be scheduled against are rejected

An Invalid Date compares false against everything, so a list holding one sorts into no order and
the scan that assumes order can walk past a real meeting. Both boundaries must now be real dates and
the interval must not end before it starts — checked where the caller can still see which input was
wrong, rather than becoming undefined behaviour three layers down.

They are also copied in and out. getBusyTimes() documented itself as safe to modify while handing
back the scheduler's own objects.

5. The release checks now check something

• version-check only ran when a PR title began with v, so it skipped every PR written to the
  commit convention — including the last three bug fixes. It runs on every PR now.
• Publishing fired on both the release and its tag, so a tagged release ran twice and the loser
  failed on an already-published version. The release is the only trigger, and it refuses to publish
  unless its tag names the version in package.json. Tag v0.5.0 pointing at 0.5.1, and 0.5.1
  reaching npm a minute before 0.5.0, are what that check exists to prevent.
• publint now reports clean: sideEffects, engines, declared provenance, and the TypeScript peer
  dependency moved to dev.

Tests

New: a sweep over the wall-window resolver — 8 zones × 9 dates × 7 window shapes, >1000 probes —
asserting an invariant rather than expected outputs: every returned instant must read, on the
host's clock, as a time inside the window. The two defects fixed in 0.6.0 and 0.7.0 were each an
answer someone wrote down by running the code, so the tests agreed with the implementation and could
not disagree with the bug. This one can.

Also new: the daily-window cases (three of four fail against the previous code) and the busy-time
ingest cases.

Two existing tests asserted the old answers. One expected six slots where the day holds four — its
own comment said it described "what the implementation yields". The other expected the one-minute
sliver.

537 pass, typecheck and lint clean. Coverage 95.98% lines / 95.30% funcs, marginally up;
every file touched here is at 100% except the invalid-timezone guard.

Performance

Measured against the branch point, since this adds work per resolution:

scenario	before	after
week with a daily window + timezone	610ms	213ms
week of availability pattern	18ms	9ms
8 weeks of pattern + maxOverlaps	137ms	87ms
Scheduler constructor, 500 busy times	0.27ms	1.5ms

The constructor is the one real cost — about 3µs per busy time to validate and copy it, which is the
price of not letting an Invalid Date reach the scheduler. Everything else got faster: the offset
lookup no longer rebuilds an Intl.DateTimeFormat per call, and a span whose ends share an offset
cannot contain a transition, so the common day takes two lookups instead of one per hour.

CI is pinned to TZ=UTC, and that is a gap rather than a decision

The library's answers must not depend on where it runs, and its own code no longer does. But 48
tests still assume the host clock is UTC — all for exported utilities (startOfDay, isSameDay,
alignToInterval, getTimeWithinDay) that read it by design. A matrix now would mean
permanently red checks, which teach people to ignore CI. The comment in tests.yml says what has to
go first; the 1.0 plan removes those exports.

codecov/patch is failing on this PR. The patch is well covered by the numbers above; the check is
not required by the ruleset.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 99.13793% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/helpers/time/timezone.ts	98.43%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!