Seconds, milliseconds and Cron: make the timezone explicit

Confirm the unit with a known value

Unix timestamps count time from 1970-01-01T00:00:00Z. APIs commonly use seconds; JavaScript Date uses milliseconds. A modern 10-digit timestamp is often seconds and a 13-digit one milliseconds, but length is only a heuristic.

Both values below represent the same instant. Nav Tools detects common forms automatically; select the unit explicitly for historical, negative or unusual-length values.

Seconds:      1704067200
Milliseconds: 1704067200000
UTC:          2024-01-01T00:00:00.000Z

An instant is not a timezone

Changing a timezone changes the calendar display, not the instant represented by a timestamp. The example is 00:00 in UTC and 08:00 in Asia/Shanghai. An offset such as +08:00 describes one offset; an IANA zone carries historical daylight-saving rules.

A date-time without an offset needs an agreed timezone. Avoid comparing strings from different zones as if they were instants. Convert both to timestamps or explicit ISO 8601 offsets first.

Preview Cron in the target zone

For standard five-field Cron, the order is minute, hour, day of month, month, day of week. The example requests 09:00 on Monday through Friday in the chosen timezone.

Nav Tools lets you choose a timezone, starting time and 10/20/50 future runs. The start is exclusive. Day-of-month and weekday restrictions use OR; a different scheduler may use different dialect rules.

0 9 * * 1-5

Inspect the clock-change boundary

Some local calendar times do not exist when clocks move forward, and others occur twice when clocks move back. A daily 02:30 task is not guaranteed to behave identically across schedulers.

The timestamp converter rejects ambiguous or nonexistent offset-free local times. Cron previews follow cron-parser’s DST behavior. Check dates around the transition and confirm the deployed scheduler’s policy before relying on the schedule.