Unix Timestamp Converter
Convert between Unix seconds, Unix milliseconds, local time, UTC, and ISO 8601 without sending your values anywhere.
Timestamp and date converter
Calculations run locally in this browser.
Conversion result
What is a Unix timestamp?
A Unix timestamp is a number that represents elapsed time since 1970-01-01 00:00:00 UTC, commonly called the Unix epoch. Most APIs use either seconds (for example, 1721563200) or milliseconds (for example, 1721563200000).
Methodology and assumptions
- For timestamp input, the selected unit is converted to JavaScript milliseconds before formatting.
- For date input, the browser interprets the date and time in your current local time zone, then calculates Unix time from that instant.
- UTC output uses the browsers standard date formatter; ISO 8601 output is the equivalent UTC string with a trailing
Z. - Fractional seconds are accepted where the browser can represent them, while displayed Unix values are kept precise up to JavaScripts safe date range.
Limitations
This tool does not infer an unknown time zone from a plain date, handle leap seconds, or validate application-specific timestamp conventions. JavaScript dates are limited to approximately 8.64 quadrillion milliseconds from the epoch. Values outside that range are rejected.
Sources and references
For the underlying definitions and formatting behavior, see the POSIX definition of seconds since the Epoch, MDNs JavaScript Date reference, and the RFC 3339 date and time profile.
Understanding Unix Timestamps
A Unix timestamp represents an instant as the number of elapsed seconds since 1970-01-01 00:00:00 UTC, commonly called the Unix epoch. Some systems store the same concept in milliseconds, so identifying the unit is essential. A value with thirteen digits is often milliseconds, while a ten-digit value is often seconds, but digit length alone should not be treated as proof.
Use seconds when working with APIs, command-line tools, databases, or systems that document seconds since the epoch. Use milliseconds when working with JavaScript Date values and many browser or application logs. This converter shows both forms so you can compare the value before passing it to another system.
UTC and local time are different displays of the same instant. The local output depends on the browsers time zone, while the UTC output is stable for communication and debugging. ISO 8601 output is useful because it includes a clear date and time structure and can include a UTC marker. When investigating logs, confirm whether the source uses UTC, local time, seconds, milliseconds, or another precision before comparing timestamps.
Timestamps do not automatically describe business calendars, holidays, leap seconds, or a users preferred time zone. For scheduling or compliance workflows, keep the original timestamp, document its unit, and use a time-zone-aware library or database type where appropriate.
Additional Timestamp Checks
A common debugging mistake is comparing a timestamp in seconds with one in milliseconds. The values may differ by a factor of one thousand and can appear to point to a date far in the future or far in the past. When an API returns an unexpectedly large number, inspect its documentation before changing the value. Convert it once, record the original unit, and avoid repeatedly multiplying or dividing the same value.
For application logs, a timestamp is usually best stored alongside an event identifier and a clear time-zone convention. For user displays, convert the instant to the reader locale only at the presentation layer. This keeps storage and comparisons consistent while making dates understandable to people in different regions.
The converter is deliberately simple and local. It does not send the entered value to a server, look up a location, or infer business meaning. It helps you inspect and translate a timestamp; the surrounding application remains responsible for validation, authorization, retention, and correct handling of dates.
Testing Timestamp Integrations
When moving a timestamp between systems, preserve the original integer before formatting it for display. A formatted local date is convenient for people but can lose precision or timezone context. For tests, include a known epoch value, a value around midnight UTC, and a daylight-saving transition in the target region. These checks help reveal unit errors and assumptions that ordinary examples may hide.
Document the chosen unit in API contracts, database fields, and log descriptions. This small habit prevents future developers from guessing whether a value means seconds, milliseconds, or another precision. It also makes migrations and incident investigations much easier.
Timestamp FAQ
Why does the same timestamp show different local times?
A timestamp represents one instant, but local display depends on the viewer's time zone and daylight-saving rules. If two teammates see different clock times, compare the UTC output first. UTC gives a shared reference point, while local time is only the regional presentation of that instant.
Should databases store local time or UTC?
For most logs and system events, store UTC plus a clearly documented unit. Convert to local time only when showing the value to a user.