Unix timestamps: seconds, milliseconds and local displays
Understand what the number represents before using it in an export, log or integration.
A number representing an instant
A conventional Unix timestamp counts seconds relative to 1970-01-01 at 00:00:00 UTC, using the system’s Unix-time convention. It is not a local clock reading and does not contain a city name. Displaying the same timestamp in Tokyo and London produces different local readings for the same instant. Our timestamp converter is useful for inspecting a value, but first identify the unit expected by the system that produced it.
Seconds and milliseconds are easy to confuse
Many interfaces use seconds, while JavaScript’s Date values use milliseconds. Confusing them can produce a date near the epoch or far outside the intended range. Do not rely solely on the number of digits: consult the field’s documentation, then test a known value. Preserve fractional precision when it matters, and avoid silently rounding a high-resolution timestamp before using it to order events.
Keep local scheduling information separately
A timestamp can identify a completed event or a single deadline, but it does not fully describe “09:00 every Monday in Paris.” That recurring instruction needs a local schedule and time-zone rules. Likewise, a birth date or an all-day holiday is a calendar date, not necessarily an instant at midnight UTC. Choosing the wrong representation can shift the displayed day when software converts it for another region.
A reliable troubleshooting workflow
Record the raw value, its unit, the expected UTC instant and the location used for display. Compare UTC first, then the local conversion. If UTC is wrong, investigate parsing or units; if UTC agrees but the local display differs, inspect time-zone settings and data versions. Keep original log values when correcting presentation. Our data-update guide explains rule changes, and the UTC guide provides a readable timestamp format for sharing your findings.
Sources
Related reading
UTC and local time: a practical explanation
Learn what an offset tells you, what it leaves out and how to write an unambiguous time.
Why time-zone data updates matter even when your clock looks right
A policy change has to reach your software before future local times can be calculated correctly.
IANA’s Moldova correction shows why the transition hour matters
The 2026a release corrects how software represents clock changes dating from 2022.
No leap second at the end of December 2026
The IERS announcement confirms a normal end to December's UTC minute. This is separate from daylight saving and leap years.