Timestamps and scheduling guides
Cron timezone migration: preserve local time or the instant
Choose the intended invariant when moving a schedule between UTC and a named local timezone.
Choose what must stay constant
Moving a schedule from one timezone to another can preserve the wall-clock hour or preserve the UTC instant. Those are different requirements.
For a local business opening time, the named local timezone is usually the relevant rule. For coordinated global work, UTC may be the rule.
09:00 Asia/Shanghai = 01:00 UTC
Local rule: 0 9 * * * with timezone Asia/Shanghai
UTC rule: 0 1 * * * with timezone UTCDo not replace an IANA zone with one offset
A daylight-saving zone can have different UTC offsets across the year. One converted hour cannot preserve a fixed local time year-round.
Preview dates in both seasonal offsets before changing a deployment from local time to UTC.
09:00 America/New_York:
Winter: 14:00 UTC
Summer: 13:00 UTCSet timezone through the scheduler interface
Timezone configuration is scheduler-specific. Kubernetes has spec.timeZone, while other systems use separate settings or environment rules.
Do not paste TZ or CRON_TZ into every expression. Nav Tools selects timezone in its options, separately from the five fields.
Plan the cutover boundary
Old and new schedules can overlap during migration or leave a gap. Record the last old scheduled instant and the first new one.
Use the scheduled instant as part of an idempotency key and inspect both sides of the switch before disabling the previous rule.