Unix timestamps: the four traps that break your dates

A Unix timestamp is just a count of seconds since 1970-01-01 UTC. Simple — yet timestamps cause more date bugs than any other format. Four traps explain most of them.

1. Seconds vs milliseconds

JavaScript's Date.now() returns milliseconds; classic Unix time and most backend logs use seconds. A 10-digit number is seconds, 13 digits is milliseconds. Mixing them turns 2026 into dates in the year 53,000 — or in 1970.

2. UTC vs local time

The timestamp itself has no timezone — it is the same instant everywhere. Bugs appear when code converts it with the server's timezone instead of the user's, or when a string like 2026-09-01 08:00 is parsed without saying which zone it belongs to.

3. Daylight saving shifts

Zones with DST jump an hour twice a year. A meeting stored as 09:00 local in summer and winter is two different UTC instants; storing UTC and converting at display time avoids the whole class of bugs.

4. Locale-dependent parsing

Strings like 03/04/2026 mean March 4th in one country and April 3rd in another. Parsing dates from text needs an explicit format — never guess.

The working rules: store UTC, convert only for display, and always label your formats. To inspect a timestamp or a date string, convert it with the timestamp tool or compare world clocks side by side — both run locally in your browser.