#5624: add support_human_readable_time_format in cron

## Summary One-shot cron jobs (`schedule.kind: "at"`) no longer require callers to send Unix timestamps. Agents and tools can send a human-readable `at` string (and optional `tz`) instead, avoiding timestamp math and timezone mistakes. ## Problem - Models struggle to convert phrases like "tomorrow 11pm" into correct Unix ms. - Off-by-one or timezone errors can create jobs in the past, so they are marked `enabled: false` / `lastStatus: "ok"` without running (e.g. user: "提醒我睡觉" → job 1 minute after scheduled time). ## Solution - **`schedule.at`** (string): ISO 8601 with offset (e.g. `2026-02-01T23:00:00+08:00`) or local datetime without offset (e.g. `2026-02-01 23:00:00`). - **`schedule.tz`** (optional): IANA timezone when `at` has no trailing `Z` or offset (e.g. `Asia/Shanghai`). - Gateway normalizes to `atMs` before validation and storage; existing `atMs` (number) remains supported. ## Changes - **`src/cron/parse.ts`**: `parseAbsoluteTimeMs(input, tz?)` — optional `tz`; if set and string has no offset, interpret as local time in that IANA zone (Intl-only, no new deps). Round to whole seconds when input has no fractional part. - **`src/cron/normalize.ts`**: Coerce `schedule.at` / `schedule.atMs` (string) using `schedule.tz`; strip `at` and `tz` from stored schedule. - **`src/agents/tools/cron-tool.ts`**: Tool description updated to recommend human-readable `at` (with optional `tz`). - **`docs/automation/cron-jobs.md`**: Schedules and JSON examples updated for `at` + `tz`. - **Tests**: `src/cron/parse.test.ts` (new), `src/cron/normalize.test.ts` (new case for `at` + `tz`). ## Example { "kind": "at", "at": "2026-02-01T23:00:00+08:00" } { "kind": "at", "at": "2026-02-01 23:00:00", "tz": "Asia/Shanghai" } <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR adds support for specifying one-shot cron schedules as a human-readable `schedule.at` string (optionally with `schedule.tz` IANA timezone) instead of requiring callers to send epoch milliseconds. Gateway normalization now coerces `at`/string `atMs` into numeric `atMs` using the updated `parseAbsoluteTimeMs(input, tz?)`, and docs/tool descriptions are updated accordingly. The change primarily touches the cron input normalization layer (`src/cron/normalize.ts`) and time parsing utilities (`src/cron/parse.ts`), with new tests covering ISO strings and timezone-local parsing behavior. <h3>Confidence Score: 4/5</h3> - This PR looks safe to merge after addressing one correctness issue around stripping `tz` during inferred-kind normalization. - Core behavior (parsing/normalizing `at` to `atMs`) is localized and covered by new tests, but `normalize.ts` currently only deletes `tz` when the original input included `kind: "at"`, which can cause unexpected persisted fields when `kind` is inferred. The timezone parsing logic is non-trivial but appears deterministic and guarded against invalid IANA zones. - src/cron/normalize.ts; src/cron/parse.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->