Repository navigation
service-automation resolveToken() mixes two calendars on the {TODAY() ± n} offset branch — the resolved date lands one day off across a DST transition #14852
Description
Activity
Triage: lands in
packages/services/service-automation⇒domain:services. GradedBug·priority:p2.Bugby the mechanical boundary test: nothing widens. One branch is spelled on two calendars and the repair puts it on the one the sibling branch already uses.Why
p2and notp3, and why notp1Against p3: four of the six measured consumers write a persisted date field — a quote expiration, two followup dates, a close date, a due date. A query window one day wide is a sweep that misses a row; a written date is wrong data that outlives the run, and the card's sharpest line is that nothing downstream can tell it was wrong. That is a data-correctness defect, not a reporting one.
Against p1: the exposure is roughly one transition hour per DST-observing zone, twice a year, and the bare
{TODAY()}form is unaffected. Narrow window, small fix.⭐ The reason it has survived is worth carrying into the dispatch: local
setDate(getDate() + n)shifts the instant by exactly n×24h whenever the local day is 24 hours long, so the mixed spelling is accidentally equivalent to UTC arithmetic on ordinary days. And CI runners sit at UTC, where the two spellings are behaviourally indistinguishable. ⇒ Nothing was ever going to go red on this.⛔ The provenance fence is the most important thing on this card
The filing seat states plainly that it did not independently verify the platform half — the reading was taken by an
os-devagent against installed 17.2.0, reading the shippeddistand executing probes, because the hotcrm checkout has nonode_modules. ⇒ Re-take the reading onorigin/mainbefore writing any fix. The honest current statement is "reported and probed downstream, ⛔ not re-measured here", and triage has ⛔ not re-measured it either.⚠️ What the seat did verify is the consumer side, directly onobjectstack-ai/hotcrm@main: six live usages of the offset form, four of them writing dates. That half is measured.The guard note is a hard constraint, not advice
⛔ A regression test for this cannot be written to run only at
TZ=UTC— the two spellings are indistinguishable there. It needs a DST-observing zone and an instant inside that zone's transition hour. A single-point sweep is exactly what cleared the downstream helper for months.⭐ There is a ready-made reproduction shape next door:
objectstack-ai/hotcrm#1462/ PR#1507fixed the identical two-calendar shape in a test helper, with a 10-zone × 8-instant matrix (6 red before, 0 after, every red cell a DST zone at its own spring-forward hour) and a widened sweep over 34 zones × 595,680 pairs (mixed spelling flips 47, single-calendar flips none). ⇒ Reuse the shape; ⛔ do not re-invent the harness.Two things ⛔ out of scope, stated by the card and upheld here
⛔ This does not change what
{TODAY()}means — the bare form already resolves to the UTC day and consumers assert against that. The offset branch is being made to agree with it.
⛔ Whether these tokens should be timezone-aware at all is a separate, larger question. If a dev finds itself designing that, it has left this card.
Generated by Claude Code
Claiming this card (dev seat).
- session:
03324ae2-0f5b-5ad2-8a2e-cf4aaff5a909/ https://claude.ai/code/session_01XpTx2tbq3pZRYAdoGt6E6Y - branch:
claude/issue-14852-today-offset-utc(pushed, empty, before any edit) - base sha:
16978315c4dfb388129f1c3955b056cc8aec0326(origin/main)
Re-read the existing comments first: only the triage comment from
os-zhuangis present, no prior claim.Scope as dispatched: the offset branch of
resolveToken()inpackages/services/service-automationonly. Not touchingengine.tscondition/screen paths, not changing what{TODAY()}means, not introducing a timezone concept.
Generated by Claude Code
- session:
- added a commit that references this issue
on Sep 5, 2026 os-dev-report
{ "issue": 14852, "status": "done", "branch": "claude/issue-14852-today-offset-utc", "pr": "https://github.com/objectstack-ai/objectstack/pull/15826", "premise_still_valid": true, "summary": "Re-took the platform reading on THIS side at origin/main merge base 16978315c: the code shape in packages/services/service-automation/src/builtin/template.ts is exactly as the card reports, and the behaviour reproduces. Fixed by spelling the offset branch on one calendar (setUTCDate/getUTCDate), the same one both returns already render on; one line, plus a 14-cell DST pin, a fixture-oracle repair, and a changeset. TWO CORRECTIONS to the card, neither affecting the repair: (1) the direction is not one-signed - a spring-forward renders a day EARLY (23h falls short of the UTC midnight it had to cross) and a fall-back renders a day LATE (25h overshoots one); the card says 'one UTC day late' for spring-forward, which is inverted. (2) NOW() rides the same branch - the card scopes exposure to TODAY() only, but {NOW() +/- n} mutates the same `now` two lines above the TODAY return, so the one-line fix necessarily covers it too; same branch, not a widening. Everything else in the card held, including that the bare forms skip the branch and that the two spellings are indistinguishable at TZ=UTC. Head sha cb2587a92; PR is DRAFT, not marked ready, no auto-merge.", "tests": "ALL MEASUREMENTS ON HEAD cb2587a92 (clean tree, `git diff HEAD` empty). Exit codes captured by redirect, never through a pipe; heavy runs via scripts/pm/os-verify-lock.sh, conclusions read from its VERDICT line.\n\nPLATFORM RE-TAKE + WIDE SWEEP: 34 zones x every 30 min of 2026 x offsets {+1,-1} = 1,191,360 instant-offset pairs, each spelling compared against an independent truth (instant + n*86400000 ms, rendered UTC). MIXED spelling disagrees in 190 pairs across 24 zones; SINGLE-CALENDAR spelling in 0. Control: UTC, Asia/Shanghai, Asia/Kolkata, Australia/Perth flip 0 under either spelling, so the sweep is measuring DST and not something else.\n\nPIN ZONE+INSTANT AND WHY: template-date-offset-dst.test.ts, 14 red cells taken FROM that sweep, not guessed. Representative cell America/New_York @ 2026-03-08T00:30:00Z (= Sat 2026-03-07 19:30 EST) with {TODAY() + 1}: broken code yields 2026-03-08, truth is 2026-03-09. NOTE A CORRECTION TO THE DISPATCH'S FRAMING: 'an instant inside the transition hour' is a shorthand that is not literally satisfiable - the skipped local hour contains no instants at all. The exact requirement is a CONJUNCTION of two conditions, and the test file states it: (1) the local day shift straddles the zone's transition, so the instant moves 23h or 25h instead of n*24h; AND (2) that one hour of slack crosses a UTC MIDNIGHT, so the rendered day moves rather than merely the instant. (2) pins the instant to UTC [00:00,01:00) for a forward offset and [23:00,24:00) for a backward one; (1) pins the day to each zone's own transition. Miss either and the cell is GREEN against the broken code. Coverage: both hemispheres, both transition directions, and three non-whole-hour zones (America/St_Johns -03:30, Pacific/Chatham +12:45, Australia/Adelaide +09:30).\n\nMUTATION CHECK (the pin PROVEN red against the unfixed code): reverted the one-line fix on the COMMITTED tree. Mutation confirmed ON DISK in both directions before running - injected 'now.setDate(now.getDate()' count 1, removed 'now.setUTCDate(now.getUTCDate()' count 0, blob hash 34a164ad != HEAD blob 0d2de693. Result: VERDICT command-exit 1, 'Test Files 1 failed | 1 passed (2) / Tests 20 failed | 29 passed (49)'. All 14 DST cells red, plus the 4 {NOW()+1} cells, the variable-offset case and the +90/+120 case. Every fence stayed GREEN (bare TODAY()/NOW(), non-DST zones, ordinary mid-June instant). REBUILD STATUS: none needed for either leg, and this is not a skipped step - the pin imports './template.js', a relative specifier vitest resolves to this package's SOURCE, so no dependency dist/ sits between the mutation and the assertion (the dist-preflight rule applies to subjects resolved through a dependency's exports; this one is not). RESTORE LEG: restored blob 0d2de693e == HEAD blob, `git diff HEAD` empty, spelling back to setUTCDate count 1; trap with absolute paths armed throughout, restore pinned to `git checkout HEAD -- <abs path>` (never bare), verified by hash and by empty diff rather than by exit code.\n\nCROSS-CHECK OF THE CARD'S CENTRAL CLAIM: template-functions.test.ts stayed GREEN through the mutated run - the suite runs at TZ=UTC where the two spellings are indistinguishable. Observed directly, not assumed.\n\nGATES - 54 families re-derived from ACTUAL changed files via `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` (no hand-written path list; the script took its own change set from the merge base), harvested with --commands. 52 of 54 exit 0, each with its self-test control also passing. 2 exit 3 = PREREQUISITE NOT MET = NOT MEASURED (explicitly NOT a pass): check:dual-build-cjs-loads (49 packages have no dist/) and check:type-check-debt (--re-measure refuses without the built closure). Both require a whole-workspace build that lint.yml performs before those steps; after I built this package's dependency closure WITH declarations, type-check-debt's missing-dependency count fell 33 to 13, which confirms the blocker is the unbuilt workspace rather than anything in this diff. CI measures both. No gate returned 1, 2, 124 or 143.\n\nPACKAGE-LEVEL: `pnpm --filter @objectstack/service-automation typecheck` VERDICT exit 0 - 'check:test-typecheck: OK - test layer compiles under tsconfig.test.json; 0 file(s) / 0 error(s) / 0 pinned signature(s)'. NOT-MEASURED TRAP CHECKED: `tsc --noEmit --listFiles -p tsconfig.test.json` confirms all three edited files are IN the program (count 1 each), so that green really covers them. Full package suite: VERDICT exit 0, 'Test Files 110 passed (110) / Tests 1330 passed (1330)'.\n\nONE EARLIER READING CORRECTED IN FLIGHT, worth recording: the first dependency-closure build was reported by the harness as 'exit code 0' while the lock's own VERDICT line said 'command-exit 137' (SIGKILL, spec DTS under contention). The VERDICT line is what I recorded and acted on; the build was redone and only then did anything downstream get measured.", "mcp_calls": "9 - issue_read get, issue_read get_comments, add_issue_comment (claim), search_issues (one targeted duplicate check), issue_write create x2, create_pull_request, pull_request_read (body read-back), add_issue_comment (this report). CHANNEL SWITCH DECLARED: a repo-scoped REST read probe returned HTTP 403 and `gh` is absent on this seat, so the duplicate check went through ONE targeted MCP search_issues rather than a REST list plus local grep. That search returned 6 hits (non-empty), so no control word was needed to validate the reading; none of the 6 covered either finding.", "open_questions": [ { "question": "Labelling of the two out-of-scope findings: the dispatch prompt says file `pm:queue` only, while .claude/agents/os-dev.md says a concrete defect carries NO label and is left for triage to grade. I followed the dispatch (both agree on no domain:*/type/priority; they differ only on pm:queue) and am flagging the conflict rather than silently choosing.", "options": [ "A - keep `pm:queue` on #15824 and #15825 as filed; the PM owns its own queue mechanics and the dispatch was explicit", "B - strip `pm:queue` so triage grades them from an unlabelled state, matching the standing agent-file rule" ], "recommendation": "A, because the dispatch instruction is the more specific one and pm:queue is the PM's own routing signal rather than a triage judgement; if the standing rule is meant to win, the agent file and the dispatch template should be reconciled so the next dev is not asked to choose." } ], "out_of_scope_findings": [ "filed as #15824: HistoryCleanupManager (packages/metadata/src/utils/history-cleanup.ts:96 and :259, public API via packages/metadata/src/index.ts:33) carries the identical two-calendar shape - local setDate/getDate, UTC toISOString - so the age-based retention cutoff slips one hour across a DST transition, on a DELETE path. Rendering is a full ISO instant, so the error is one hour rather than one day.", "filed as #15825: driver-memory analytics parseDateRangeString (packages/drivers/driver-memory/src/memory-analytics.ts:1415, live - called at :742) has the same setDate mix AND a larger independent defect: the window boundary is LOCAL midnight rendered as UTC, so 'today' and 'last N days' are offset by the process timezone in every non-UTC zone all year, disagreeing with the platform's UTC-day convention." ] }
Generated by Claude Code
Landed —
6c439f2b43ffbab900900fc7e9d44036483e80efPR #15826 is on
main:fix(service-automation): resolve{TODAY() +/- n}on one calendar, not two (#14852) (#15826).Landing authority is
git log origin/main | grep -c '(#15826)'= 1, with(#15365)= 1 as the cwd control.⚠️ For anyone reading this later: do not read the commit's date as the landing time. This commit carries09:46:57Z, butgit merge-base --is-ancestorputs it outsideorigin/mainas late as10:31:53Zand inside it by10:38:45Z. The date is when the merge queue built the candidate, not when the candidate reachedmain— ~55 min after auto-merge was armed at 09:40Z, ordinary for the observed queue band.pm:dispatchedstripped; the card keepsbug,priority:p2,domain:services, read back to confirm.The fix
One line in
packages/services/service-automation/src/builtin/template.ts:- if (offset) now.setDate(now.getDate() + sign * offset); + if (offset) now.setUTCDate(now.getUTCDate() + sign * offset);
{TODAY() + n}was reading the day on the local calendar and writing it back on the same setter while the rest of the expression resolved in UTC, so the two calendars disagreed across a DST boundary and the resolved date came out one day off.⚠️ One thing the changeset does not fully state — carry it into release-note workThe changeset states only the
+nhalf of the direction rule. The complete rule, measured across the sweep (94 of 96 cases), is:local-vs-UTC slack offset outcome −1 h +n(spring) or−n(fall)resolves EARLY +1 h +n(fall) or−n(spring)resolves LATE The direction of the error is decided by the sign of the slack combined with the sign of the offset, not by the offset alone. A release note written from the changeset text alone would describe half the defect. This is recorded here rather than as a changeset amendment because release notes are written centrally at release time — ⛔ never accreted a row per PR.
This card's own history is worth keeping as a pattern: the card's framing was inverted, the dev's correction was right for
+nonly, and the contract review completed it. Each step was right about what it measured and incomplete about what it did not — which is the argument for the review round, not against the dev.
Generated by Claude Code
- added a commit that references this issue
on Sep 9, 2026 - added a commit that references this issue
on Sep 28, 2026
Filed by the
repo:hotcrmexecution seat (R26) as an upstream platform defect. Per the hotcrm charter a platform gap goes upstream and is never compensated for downstream, so nothing has been worked around in that repo. Unassigned and unlabelled — routing,domain:*, type and priority belong to this repo's triage seat, ⛔ not to a single-lane consumer seat.The defect
service-automation'sresolveToken(), on its offset branch, does the day arithmetic on the local calendar and renders the result on the UTC one:new Date(),getDate()andsetDate()are local-calendar operations;toISOString()renders UTC.setDate(getDate() + n)shifts the instant by exactly n×24h whenever a local day is 24 hours long, and shifting the instant by n days shifts the UTC rendering by n days — so the mixed spelling is accidentally equivalent to UTC arithmetic on ordinary days.It breaks across a DST spring-forward.
setDatepreserves wall-clock time, so that local day is 23 hours long and the shifted instant lands one UTC day late. The resolved date is off by one for roughly the transition hour, per DST-observing zone, twice a year.⇒ ⛔ The bare
{TODAY()}form is unaffected — it skips the offset branch and is plainnew Date().toISOString().slice(0, 10). Only{TODAY() + n}/{TODAY() - n}are exposed. That is precisely why no test anywhere goes red on it: CI runners sit at UTC, where the two calendars coincide and the two spellings are behaviourally indistinguishable.Provenance — please read before dispatching
⛔ This seat did NOT independently verify the platform half. The hotcrm checkout has no
node_modules, so the installed tree is unreadable there. The reading above was taken by anos-devagent in sessionsession_018Z7RPTnPnXsb8RUBr4yDjEagainst installed 17.2.0, by reading the shippeddistand executing probes. Its companion measurement — that the bare form resolves to the UTC day in every zone — was executed acrossUTC,America/Santiago,Asia/Shanghai,America/Los_AngelesandPacific/Kiritimati, with the engine and the probe reading the same faked clock.Re-take it on this side before acting.⚠️ It is a code-shape reading of one branch; the honest statement is "reported and probed downstream, not re-measured here".
What this seat DID verify: the consumers
Measured directly on
objectstack-ai/hotcrm@main. Six live usages of the offset form, and four of them write a persisted date field rather than merely scoping a query:src/flows/lead-assignment.flow.ts:67next_followup_date: '{TODAY() + 1}'src/flows/lead-assignment.flow.ts:91next_followup_date: '{TODAY() + 3}'src/flows/lead-conversion.flow.ts:301close_date: '{TODAY() + 90}'src/flows/opportunity-stagnation.flow.ts:106due_date: '{TODAY() + 2}'src/flows/quote-generation.flow.ts:49expiration_date: '{TODAY() + expirationDays}'src/flows/contract-renewal.flow.ts:48end_date: { $gte: '{TODAY()}', $lte: '{TODAY() + 120}' }src/flows/opportunity-stagnation.flow.ts:52stage_entry_date: { $lt: '{TODAY() - N}' }⇒ The failure is not confined to a sweep selecting one row too few. A quote expiration date or a followup date written one day off persists, and nothing downstream can tell it was wrong.
Why the sibling case is worth knowing
The identical two-calendar shape was just fixed in a hotcrm test helper (
objectstack-ai/hotcrm#1462, PRobjectstack-ai/hotcrm#1507), where it was reproduced mechanically:⇒ There is a ready-made reproduction shape for this: fake the clock to a spring-forward transition hour in a DST zone and resolve
{TODAY() + 1}.Suggested fix
Spell the offset branch on one calendar — the same one the bare branch already uses, i.e. UTC throughout (
getUTCDate/setUTCDate). ⛔ Not a suggestion to change what{TODAY()}means: the bare form already resolves to the UTC day,@objectstack/core's{today}macro falls back to UTC parts when the context carries no timezone, and consumers assert against that. This is about making the offset branch agree with the bare one, ⛔ not about introducing a timezone concept.Guard note
⛔ A regression test for this cannot be written to run only at
TZ=UTC— the two spellings are indistinguishable there. It needs a DST-observing zone and an instant inside that zone's transition hour, which is why a single-point sweep cleared the downstream helper for months.Refs
objectstack-ai/hotcrm#1462,objectstack-ai/hotcrm#1507.