Unix 时间戳指南：秒毫秒与时区陷阱

Timestamps look trivial until a batch of logs is off by three hours or a 2038 problem appears in a test environment. The field guide below covers what systems actually store and how to debug when dates misbehave.

What the epoch number really is

A Unix timestamp counts seconds since 1970-01-01 00:00:00 UTC. It carries no time zone — that is its strength. Every conversion to local hours is a display concern done at render time with the viewer zone.

Seconds vs milliseconds: the eternal mix-up

JavaScript, Java and many APIs use milliseconds; Unix tools and most databases use seconds. Mixing them shifts dates to 1970 or to year 53k. The digit-count check is instant: 10 digits is seconds, 13 digits is milliseconds — the Timestamp Converter auto-detects both and converts a whole pasted batch per line.

ISO 8601 and offsets

2026-10-12T09:30:00Z is UTC; +08:00 suffixes carry explicit offsets. Always log in UTC and render local. Anything parsed without an offset invites the server zone to guess — a source of the classic hours-off bug.

Where timestamps collide with schedules

Cron runs in server-local zones and fires on wall-clock time, while queues and metrics carry epoch values. When tracing a job from scheduler to payload, convert the fired epoch and the cron fields together — the Cron Parser plus the timestamp tool pin down the mismatch in seconds and milliseconds.

One workflow to pin any date bug

• Paste the suspicious epoch into the converter — confirm the unit by digit count.
• Compare with the ISO string the server logged.
• If hours drift, suspect a zone assumption, not math.