ReminderRouter derives "today" as the UTC day: "remind me today" silently schedules for tomorrow every evening in negative-offset zones

[MatiasBarboza]

What's broken

hooks/ReminderRouter.hook.ts derives due dates with:

function iso(d: Date): string {
  return d.toISOString().slice(0, 10);
}

toISOString() is always UTC, so between 21:00 and 23:59 in UTC-3 (and any negative-offset zone's evening), "remind me today" files an issue due tomorrow. It fails silently every night — the issue is created, the date is just wrong, so nothing ever alarms.

Version / location

• v7.40.4 (current tag), LifeOS/install/hooks/ReminderRouter.hook.ts:122-124 (iso()), used by parseRelativeDate for today/tomorrow/in-N-days/next-weekday.
• The class is wider: grep -rn "toISOString().slice(0, 10)\|toISOString().split" hooks/ LIFEOS/TOOLS/ LIFEOS/PULSE/ finds ~33 sites at the tag; most are human-facing days (due dates, created: frontmatter, "Last Updated" stamps, filenames, "Today is X" prompts to models) where the UTC day is the wrong answer for any non-UTC operator.

Repro (clean tree, no patches)

// bun repro.ts — uses only the tag's code path
const now = new Date("2026-08-01T01:06:00Z"); // == 2026-07-31 22:06 in America/Montevideo
console.log(now.toISOString().slice(0, 10));   // "2026-08-01" — but the operator's "today" is 2026-07-31

Negative control: the same derivation at midday (2026-08-20T15:00:00Z, 12:00 UTC-3) returns the correct local day — which is why the bug survives casual testing: it only exists at night, and its symptom is a reminder that quietly arrives a day late.

Root cause

The codebase has no primitive for "the LOCAL calendar day of an instant". hooks/lib/time.ts already reads principal.timezone from settings.json and has getPSTDate() (local today), but nothing converts an arbitrary Date to the principal's day, so call sites reach for toISOString().slice(0, 10).

Suggested fix

Add the missing primitive to hooks/lib/time.ts (timezone as a parameter so it's testable — bun test runs in UTC, where an environment-reading version can never fail):

export function localISODate(date: Date = new Date(), timezone: string = getTimezone()): string {
  return new Intl.DateTimeFormat('en-CA', {
    timeZone: timezone, year: 'numeric', month: '2-digit', day: '2-digit',
  }).format(date);
}

Then migrate the human-facing sites (iso() in ReminderRouter first). Two classes of site should NOT be converted: absolute event seals (full-ISO ts fields in logs) and pure date-string arithmetic that anchors on T00:00:00Z and returns to a string (e.g. AppleHealthImport.windowStart).

Running this fix in production since 2026-08-20 (26 files migrated, test suite green, regression tests red against the unpatched derivation). Happy to PR if useful.

Prior art

• healthsync hardcodes America/Los_Angeles in 3 places: every reading near local midnight is filed under the wrong day for non-Pacific operators #1762 (healthsync hardcoded America/Los_Angeles: readings near local midnight filed under the wrong day for non-Pacific operators) — same family, accepted and fixed in fix(healthsync): resolve the operator's timezone instead of hardcoding America/Los_Angeles #1783. This is that bug's twin on the other side: not a hardcoded zone, but no zone at all.
• Why not using (new Date()).toISOString() #1077 was closed with "the cases where it doesn't [use toISOString] are usually intentional … local-time semantics that ISO would obscure" and an invitation to "open a fresh issue … pointing at the file/line". This is that file and line, pointing the other way: a local-time semantic that ISO is obscuring.
• Statusline reset-time uses hardcoded America/Los_Angeles, ignores the system clock #1505, Statusline: timezone is hardcoded to America/Los_Angeles instead of reading from settings.json #734 (statusline timezone) — same root: local time was not a first-class fact.

[danielmiessler]

Fixed. iso() now formats the local calendar day instead of going through toISOString().

The rest of that file already reasoned in local time via setDate/getDay, so this was the one place that left it — which is exactly why it never surfaced for anyone at UTC or above. Verified at your boundary: 2026-08-01T01:06Z now yields 2026-07-31.

You're also right that the class is wider. I fixed the reported site; the ~33-site sweep is a separate pass, because most of those are machine timestamps where UTC is the correct answer and a blind replace would break them. Sorting the human-facing days from the rest is the actual work there.

Thanks for the repro — it made the failure obvious in one read.

[MatiasBarboza]

Two things, and the first is only a heads-up.

The fix isn't visible in the public repo yet. As of today main is still at ce046f26
(2026-08-14, the 7.40.4 release commit), and
LifeOS/install/hooks/ReminderRouter.hook.ts:122-124 there still reads:

function iso(d: Date): string {
  return d.toISOString().slice(0, 10);
}

Nothing has landed on main since the release, so this looks like the same lag you described the
same day in #1910 ("Public repo lags the private tree, so it's not visible there yet. Next release
carries it.") rather than anything going missing. Flagging it only so that someone arriving here
from a search doesn't assume the code they have is fixed.

On the wider sweep — you named the actual work, and it's done. You wrote:

the ~33-site sweep is a separate pass, because most of those are machine timestamps where UTC is
the correct answer and a blind replace would break them. Sorting the human-facing days from the
rest is the actual work there.

I did that sorting to run it here, and it's been in production since 2026-08-20. Numbers, counted at
the v7.40.4 tag: grep -rn "toISOString().slice(0, 10)\|toISOString().split" hooks/ LIFEOS/TOOLS/ LIFEOS/PULSE/ returns 45 occurrences across 33 files. Of those I converted 39 call sites
across 28 files and deliberately left the rest.

The sorting rule that fell out of it is one line: convert when a human reads the day; leave it
when the field is the absolute seal of an event. In practice both kinds live in the same file,
which is exactly why a blind replace breaks things. Two examples rather than the whole list:

LIFEOS/PULSE/checks/notification-governor.ts — four toISOString() sites, and they split two
and two:

line	code	verdict
:85, :208, :242	ts: new Date().toISOString()	leave — event seal
:136, :223	const today = new Date().toISOString().slice(0, 10)	convert — this is the key for the daily notification quota

The today sites are the interesting failure: at UTC-3 the quota rolls over at 21:00 local, so
every evening gets a second full budget and the daily cap is not daily. Same shape in
LIFEOS/PULSE/modules/syslog.ts: ts: at :82/:108/:125 stay, and :140
(LOG_PATH + "." + new Date().toISOString().slice(0, 10), the rotation filename) converts, or one
local day is split across two files every night.

LIFEOS/TOOLS/CommitmentDetect.ts:57-58 — this one is the reason I bothered with the sweep at
all:

const todayIso = new Date().toISOString().slice(0, 10);
const userPrompt = `Today is ${todayIso}.\n\nMessage:\n"""${text}"""\n\nDetect commitment...`;

Every evening in a negative-offset zone the model is told the wrong date, and then asked to
resolve relative deadlines against it. It fails the same way iso() did — silently, and only after
dark.

The exclusions, since they're the half that's easy to get wrong. Beyond event seals, one more
class must not be converted: date-string arithmetic that anchors on T00:00:00Z and returns to a
string. AppleHealthImport.windowStart is the example — there the UTC round-trip is load-bearing
and localising it introduces an off-by-one in the other direction.

Shape of the change, if it's useful: add the missing primitive to hooks/lib/time.ts with the
timezone as a parameter (not read from the environment, so it's testable — bun test runs in UTC,
where an environment-reading version can never go red), then migrate the human-facing sites. One
detail worth stealing regardless of who writes it: the regression tests have to set process.env.TZ
in a beforeEach. Without that, a test asserting local-day behaviour passes on the unpatched code
too, which is how this class of bug survives a green suite.

Happy to open the PR against whatever main looks like when the private tree lands, or to just hand
over the sorted list of the 45 sites with a convert/leave verdict on each if you'd rather do the
edit yourself. The list is the part that took the time; the edit is mechanical.