Guide
Unix timestamps explained
What Unix time measures
A Unix timestamp is an amount of time measured from 1970-01-01 00:00:00 UTC, commonly called the Unix epoch. A timestamp is a number, not a formatted date. It can be stored, compared, or sent between systems without carrying a local time zone name.
UTC matters because the reference point is fixed. The same timestamp represents the same instant for a developer in Zagreb, a server in Virginia, and a user in Tokyo. A display in a local time zone may be useful for a person, but it is a separate presentation step. Keep the original timestamp and its unit when you are debugging a conversion.
TheDevTab's Unix Timestamp tool converts values locally and shows UTC and local time. It does not upload the number or ask a remote service to interpret it.
Seconds versus milliseconds
Unix seconds count one unit per second. A current value is usually ten digits. Unix milliseconds count one thousand units per second, so a current value is usually thirteen digits. JavaScript's Date.now() returns milliseconds, while many APIs, databases, and token standards use seconds.
The conversion factor is 1,000. To turn seconds into milliseconds, multiply by 1,000. To turn milliseconds into seconds, divide by 1,000 and decide whether truncation or rounding is correct for the application. Do not repeatedly convert a value if the source contract already states its unit.
Digit count is a useful first guess, not proof. Historical dates, future dates, and custom ranges can have fewer or more digits. Convert the value and ask whether the resulting date makes sense for the event. A unit mistake often produces a date near 1970 or far in the future.
ISO dates and offsets
ISO 8601 strings can include a Z suffix for UTC or an explicit offset such as+02:00. The offset tells the parser how to map the text to an instant. A date and time without an offset may be interpreted as local time by one environment and UTC by another, so do not leave that choice implicit in an API contract.
Daylight saving changes affect local display, not the Unix reference point. If a log line says 09:00 in a local zone, preserve the zone or offset when converting it. Otherwise two systems may produce different timestamps for text that looked complete to the original author.
When writing a database field, document whether it stores seconds, milliseconds, a database native timestamp, or a string. Use one unit consistently in comparisons. A field that mixes seconds and milliseconds may look numeric while ordering events incorrectly.
JWT time claims use seconds
JWT exp, nbf, and iat claims are normally NumericDate values represented as Unix seconds. exp marks the end of the accepted lifetime,nbf prevents use before a time, and iat records when the token was issued. A decoder can show the date, but it cannot decide whether the claim is trusted.
If a token contains a thirteen-digit value, check the issuer's implementation before assuming it is milliseconds. A verifier should apply the documented policy, allow only intentional clock skew, and reject values that do not meet the application's expectations. Use theJWT Decoder for local inspection and keep decoding separate from signature verification.
A reliable conversion routine
- Identify the source format and confirm its unit.
- Convert once, keeping the original value beside the result.
- Display the result in UTC before comparing it with another system.
- Check a known date and an edge case near a unit boundary.
- Document the unit in the schema, API, or log format.
Convert Unix seconds, milliseconds, and dates in the browserwhen you need a quick local check. The tool gives you an interpretation, not an explanation of why an application produced the value.