[FEATURE] add optional timezone field (IANA tz, e.g. America/Los_Angeles) to scheduled-trigger cron expressions

Optional IANA timezone field for scheduled-trigger cron expressions is a meaningful quality-of-life improvement — users who think in local time should not need to mentally convert to UTC when writing schedules.

The current 0 22 * * * schedule without timezone context is ambiguous: is it UTC midnight, UTC 22:00, or some other interpretation? Users who set schedules expecting local time behavior and then observe UTC execution end up with triggers firing at unexpected times.

The proposed extension:

{
  "schedule": "0 22 * * *",
  "timezone": "America/Los_Angeles"
}

This fires at 22:00 Pacific time (UTC-7 in PDT, UTC-8 in PST), automatically handling daylight saving time transitions.

Implementation considerations:

1. DST transitions: IANA timezone definitions handle DST correctly. A schedule of 0 2 * * * in America/Chicago will fire at 2:00 AM CST/CDT — no extra configuration needed.

1. Spring-forward edge case: If a schedule falls into the gap created by a DST transition (e.g., 2:30 AM on the Sunday when clocks spring forward to 3:00 AM), the system should document its behavior: skip that occurrence, fire at the next valid time, or fire at the wall-clock equivalent.

1. Display in UI: The routines UI should show schedules in the configured timezone with a clear indication: "0 22 * * * (America/Los_Angeles, PDT UTC-7)".

1. Backward compatibility: Schedules without a timezone field continue to run in UTC (current behavior). Adding the field is purely additive.

This connects to the timezone-awareness issues documented in the broader campaign (temporal context injection at session start, #50499/#49084) — users who set schedules in local time expect local time behavior throughout.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/49991
2. https://github.com/anthropics/claude-code/issues/24213
3. https://github.com/anthropics/claude-code/issues/32988

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is related to issue #49991 but this is a feature request, whereas the other reports this as a bug

I came across this today. Outlining my use case and expectations,

Setting up a schedule to run every day at 8am should respect my current timezone by default (Europe/London in my case). It should be a field we can switch. cron is convenient, but usually done in BE systems in a UTC environment where DST drift is accepted. Scheduling work is more of a human centric routine management. Like, every day at 7a i want this slack message or summary digest to run, every week on wednesday at 9a I need this follow up action to create a pending action for me... etc.

claude response:

The two-field shape proposed here ({cron_expression, timezone}) is exactly right. Would unblock timezone-aware scheduling without any migration burden on existing triggers.

This issue is still very much alive and actively impacting Claude Code users.

IANA timezone support in the RemoteTrigger API is a fundamental UX requirement — users think in "Europe/London", not "UTC+0/+1 with manual seasonal adjustment". Every scheduled routine either accepts ±1 hour DST drift or requires manual correction twice a year.

Please keep this open until genuine IANA timezone support (a timezone field that accepts IANA strings like Europe/London) lands in the scheduled remote agent API.

This issue is still very much alive and actively impacting Claude Code users.

IANA timezone support in the RemoteTrigger API is a fundamental UX requirement — users think in "Europe/London", not "UTC+0/+1 with manual seasonal adjustment". Every scheduled routine either accepts ±1 hour DST drift or requires manual correction twice a year.

Please keep this open until genuine IANA timezone support (a timezone field that accepts IANA strings like Europe/London) lands in the scheduled remote agent API.

+1 — hit this setting up a twice-daily PR-triage routine (5am/1pm PT) through the cloud routine API. cron_expression is UTC-only with no timezone field, so it will silently drift to 4am/12pm PT after the November DST change and needs a manual cron edit twice a year. The proposed {cron_expression, timezone} sibling field is exactly right — k8s CronJob spec.timeZone (stable since 1.27) and systemd OnCalendar + TimeZone= are good precedent. Would remove the recurring manual fixups.