[mostafaseyedan]

Problem

On main, npm run check fails for anyone whose time zone is west of UTC, which includes all of the Americas, or at UTC+13 and later. src/core/analyzer-curiosity.test.ts sets TIME to 2026-09-30T12:00:00Z, but the analyzer groups requests by local day (toDateStr uses getFullYear/getMonth/getDate). Outside the zones near UTC, the test timestamps fall on a different local date than the tests expect. CI runs in UTC, so it passes there.

Time zone	Failing tests on main
UTC, Asia/Tokyo, Europe/Berlin, Asia/Kolkata	0
America/Chicago, America/Los_Angeles	1: resets incomplete timing at action boundaries and measures only the selected date window (TypeError: Cannot read properties of undefined (reading 'elapsedMs'))
Pacific/Auckland, Pacific/Kiritimati	7

Change

Only the test changes. TIME is now local noon on 2026-09-30 (new Date(2026, 8, 30, 12).getTime()), so every timestamp the tests build lands on the intended local day in any time zone. The analyzer is unchanged: grouping by the user's local day is the intended behavior.

Review follow-up (thanks to Sanjay Singh (@san360)): two more test files had the same problem, so they are fixed here too.

• src/core/curiosity-patterns.test.ts: MONDAY is now local noon (new Date(2026, 8, 28, 12).getTime()). On main, 3 tests fail at UTC+13/+14.
• src/core/analyzer-prompt-cache.test.ts: a localTime() helper reads each request time as a local clock time, because the date ranges are local days. On main, 16 tests fail at UTC−12 and 10 at UTC+14.

Verification

TZ=<zone> npx vitest run src/core/analyzer-curiosity.test.ts gives 54/54 in UTC, America/Chicago, America/Los_Angeles, Pacific/Honolulu, Pacific/Pago_Pago, Asia/Tokyo, Europe/Berlin, Asia/Kolkata, Pacific/Auckland and Pacific/Kiritimati. On main, the same command fails in the zones in the table above.

The three changed files together pass 84/84 in Etc/GMT+12, Etc/GMT+11, America/Chicago, UTC, Asia/Kathmandu, Pacific/Auckland, Pacific/Chatham, Pacific/Kiritimati and Etc/GMT-14. Lint (no new warnings), spellcheck and typecheck pass.

I found this while running npm run check in America/Chicago for #362.

Made with Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RLDXsjE1DMDor8E6cSLBpH

[Sanjay Singh (san360)]

Thanks so much mostafaseyedan for tracking this down and for such a clear write-up! The per-zone table made it very easy to reproduce, and keeping the change in the test (the analyzer's local-day grouping is intended) is exactly the right call.

What we checked

• Reproduced on current main: src/core/analyzer-curiosity.test.ts fails 1 test in every zone we tried west of UTC (America/St_Johns, America/Santiago, America/Chicago, America/Los_Angeles, Pacific/Honolulu, Pacific/Pago_Pago, Etc/GMT+12) and 7 tests at UTC+13/+14 (Pacific/Auckland, Pacific/Chatham, Pacific/Kiritimati, Etc/GMT-14).
• With this PR the file passes 54/54 in all 17 zones we tried, from UTC−12 to UTC+14, including half- and quarter-hour offsets (St John's, Kolkata, Kathmandu, Chatham) and zones whose DST starts inside the test's date span (Auckland, Chatham).
• typecheck, lint (no new warnings), knip, lockfile-lint, the full unit suite, build and check-size all pass. The built extension is unchanged apart from its build timestamp, so there's no effect on users.

One idea: two more files with the same pattern

While running the full npm test in different zones, we found two more test files that fail away from UTC for the same reason (a fixed UTC instant checked against local-day ranges). So with this PR alone, npm test still fails at UTC+13/+14 and UTC−11/−12:

1. src/core/curiosity-patterns.test.ts (Curiosity Prompt Quality): 3 tests fail at UTC+13/+14. Since this PR is about the Curiosity tests passing everywhere, could we apply the same one-line change here too?

   // Local noon: Prompt Quality groups by local day and week, so a fixed UTC time falls on another date in some time zones.
   const MONDAY = new Date(2026, 8, 28, 12).getTime();

2. src/core/analyzer-prompt-cache.test.ts: 6 tests fail at UTC−11, 16 at UTC−12 and 10 at UTC+13/+14, because its ranges use fromDate/toDate: DAY while the request times end in Z. Reading those times as local clock times fixes it:

   // Read each time as a local clock time: date ranges are local days, so a UTC time falls on another date in some time zones.
   const localTime = (time: string) => Date.parse(time.replace(/Z$/, ''));
   
   // in request():            timestamp: localTime(time),
   // in the sessions test:    older.lastMessageDate = localTime('2026-10-18T10:00:00Z');

With both changes, the full unit suite passes (3670 passed, 5 skipped) in Etc/GMT+12, America/Chicago, UTC, Pacific/Auckland and Pacific/Kiritimati, and the three files pass in all 17 zones. The Prompt Cache one is outside Curiosity, so a separate small PR is completely fine. In that case, could we soften the description's "npm run check fails … at UTC+13 and later" a little, since this PR on its own fixes the Curiosity file?

Next steps

Because this PR comes from a fork, its CI run is waiting for a maintainer to approve it; we'll take it from there.

Thanks again for the careful fix!

[mostafaseyedan]

Thank you so much, Sanjay Singh (@san360), for testing this in 17 time zones and for finding the other two files! I really appreciate the ready-made fixes.

I applied both in this PR, so the description needs no softening:

• curiosity-patterns.test.ts: MONDAY is now local noon.
• analyzer-prompt-cache.test.ts: the localTime() helper for request times and for older.lastMessageDate.

The three files together pass 84/84 in Etc/GMT+12, Etc/GMT+11, America/Chicago, UTC, Asia/Kathmandu, Pacific/Auckland, Pacific/Chatham, Pacific/Kiritimati and Etc/GMT-14. The previous versions of the two files fail 16 tests at UTC−12 and 13 at UTC+14, which matches your counts. Typecheck is clean, and lint has no new warnings. I also updated the description and the title.

Thanks again!

[Sanjay Singh (san360)]

Thanks a lot for the quick update, mostafaseyedan, and for the kind words! The new title and description read really well.

We re-checked the new commit on top of current main:

• The update changes only the two test files we discussed, and the changed lines match the suggestions exactly. The built extension is still unchanged apart from its build timestamp.
• The three files pass 84/84 in all 17 time zones we tried earlier, from UTC−12 to UTC+14, including half- and quarter-hour offsets and Auckland/Chatham, where DST starts inside the test dates. That covers all nine zones you listed.
• The full unit suite passes (3670 passed, 5 skipped) in Etc/GMT+12, Etc/GMT+11, America/Chicago, UTC, Pacific/Auckland and Pacific/Kiritimati.
• typecheck, lint (same warnings as on main), knip, lockfile-lint, build and check-size pass.
• We also confirmed your counts for the previous versions of the two files: 16 failures at UTC−12, 6 at UTC−11 and 13 at UTC+14.

From our side this looks good to merge once CI has run. A maintainer will approve the CI run for the fork, and spellcheck will run there too.

Thanks again, this makes npm test reliable for everyone, wherever they are!