Timezone-aware cron editor and next-run preview

[serge-ivo]

Summary

Replace the raw schedule input with a timezone-aware trigger schedule editor and next-run preview.

Why

The current schedule field accepts @daily, every N minutes, or simple UTC cron. Users think in local time and need to know exactly when a trigger will run, especially for daily digests and business workflows.

Scope

• Add timezone selection/default based on user/browser timezone.
• Add common schedule presets:
  • hourly
  • daily at time
  • weekly on day/time
  • every N minutes/hours
• Show computed next run time in local time and UTC.
• Keep raw cron mode for advanced users.
• Persist timezone/config in trigger config or schedule model.
• Update backend next-run calculation to honor timezone for supported presets.

Acceptance Criteria

• A user can schedule “daily at 8:00 AM Australia/Melbourne” and see the correct next run preview.
• Existing UTC/simple schedules still work.
• Backend computes next run deterministically across DST boundaries for supported presets.
• Console UI does not require users to type cron for common cases.
• Unit tests cover timezone next-run calculations and DST edge cases.
• E2E covers creating a scheduled trigger with a local-time preset.

[serge-ivo]

Shipped in 2d9ca12.

Verified first — accurate. Schedules were UTC and only UTC: nextRunAt matched cron fields against getUTCHours() etc., there was no timezone concept anywhere in the schema or the code, and the console's schedule control was a raw text input defaulting to @daily.

Shipped

• lib/cron-time.ts — wall-clock arithmetic against an IANA zone. A cron trigger may carry config.timezone; @daily, @weekly and 5-field cron are then matched against that zone's clock, so "daily at 08:00 Australia/Melbourne" stays 08:00 across a DST change instead of sliding an hour. Absent (or unknown) timezone still means UTC — every pre-existing trigger fires at exactly the same instant it always did.
• Interval schedules (@hourly, every N minutes) are durations, not clock times, so a zone is neither applied nor offered for them.
• Two DST edges decided explicitly and tested: spring forward places a run that falls in the gap just after the jump rather than skipping the day (a daily digest silently missing once a year reads as a broken agent); fall back fires once, not twice.
• Method: the matcher walks minutes in "pseudo-UTC" wall-clock space (integer comparison, no per-minute Intl call), and only a matching candidate is offset-solved back to a real instant and round-trip verified. Same cost as the old UTC scan.
• POST /v1/triggers/preview → next N run times, normalized schedule, jitter, and config issues.
• Console: preset schedule editor (Every hour / Daily at / Weekly on / Every N / raw cron), timezone picker defaulting to the browser's zone, jitter — and a next-runs preview showing each run in both the schedule's zone and UTC plus a countdown. PUT recomputes next_run_at when the zone changes, so the stored next run is never stale.

Deliberately not done — and this is the one judgement call worth flagging
The preview is fetched from the server, computed by the same nextRunAt the cron sweep calls. There is intentionally no client-side scheduler: a preview reimplemented in the browser is a second scheduler, and the day the two disagree the UI confidently shows a time at which nothing happens. A preview that lies is worse than no preview, so the only honest source is the code that actually runs it. The console's pure logic (lib/triggerSchedule.ts) therefore covers only what can be decided without a calendar: presets → schedule string, schedule → presets, and formatting.

Also not done: cron ranges/lists/steps (1-5, */15) — unchanged grammar; and the fall-back "which of the two occurrences" is not configurable.

Tests: 14 unit in cron-time.test.ts (real Melbourne DST boundaries both directions), 5 in triggers.test.ts (back-compat + preview), 17 in triggerSchedule.test.ts, 1 e2e.