From 12dbbe3228d386c905c6328ba59c12fa0863ff67 Mon Sep 17 00:00:00 2001 From: Lucas Winther Date: Thu, 27 Aug 2026 02:24:39 +0200 Subject: [PATCH] Fix vacuous tests in occurrence id suite MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Replace the local-vs-UTC test with a timestamp that actually straddles UTC day boundary (00:30 local on 2 September = 22:30Z on the 1st). The original test was vacuous because both readings agreed on the same calendar day. Delete the rename-stability test which was a tautology — occurrenceId never takes a title, so any pure function satisfied it. The real assertion belongs in a later task where the whole rule is passed in and a rename can be exercised. Co-Authored-By: Claude Opus 5 (1M context) --- test/recurrence.test.ts | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/test/recurrence.test.ts b/test/recurrence.test.ts index 40fe56b..ededd5c 100644 --- a/test/recurrence.test.ts +++ b/test/recurrence.test.ts @@ -113,11 +113,14 @@ describe("occurrence ids", () => { }); test("the day is the reader's local day, not UTC's", () => { - // 23:30 local on 1 September is 21:30Z — a UTC reading would label this - // occurrence with the right day here, but the reverse case would not, and - // the reader typed a local date. Assert the local reading directly. - const id = occurrenceId(RULE, new Date("2026-09-01T23:30:00").getTime()); - expect(id).toBe("myevent:k3f9qa2m01#2026-09-01"); + // 00:30 local on 2 September is 22:30Z on the 1st, so the two readings + // disagree about which day this is. That disagreement is the whole point: + // the reader typed a local date and is shown a local date back, and a UTC + // reading would file this occurrence under the previous day for every + // reader east of UTC. Asserted with an instant where the two differ, + // because an instant where they agree proves nothing. + const id = occurrenceId(RULE, new Date("2026-09-02T00:30:00").getTime()); + expect(id).toBe("myevent:k3f9qa2m01#2026-09-02"); }); test("the rule id is recoverable, and a plain id is its own rule", () => { @@ -138,14 +141,6 @@ describe("occurrence ids", () => { expect(isCustomEventId("myevent:k3f9qa2m01#2026-09-01")).toBe(true); }); - test("renaming a rule cannot move its occurrence ids", () => { - // The title is not an input here, and that is the guarantee: the token is - // random precisely so fixing a typo never costs the marks attached to it, - // exactly as mintCustomEventId describes. - const start = new Date("2026-09-01T09:00:00").getTime(); - expect(occurrenceId(RULE, start)).toBe(occurrenceId(RULE, start)); - }); - test("CustomEventId REJECTS an occurrence id", () => { // The guardrail, asserted rather than assumed. '#' is outside [a-z0-9], so // an occurrence cannot be written back into the customEvents store and