How to use Unix Timestamp
- 1. Paste an epoch. Seconds (10 digits around now) or milliseconds (13 digits) are detected automatically. You can override the unit.
- 2. Read the calendar time. See ISO-8601 UTC, relative time, and a set of common time zones including Asia/Kolkata.
- 3. Pick a local datetime. Use the datetime picker to generate seconds and milliseconds for logs or JWT exp claims.
- 4. Copy the format you need. ISO, integer seconds, and milliseconds are one click each.
About this tool
Unix time counts seconds since 1970-01-01T00:00:00Z, ignoring leap seconds in the usual POSIX definition. It is the backing representation for `Date` in JavaScript (as milliseconds), for `exp`/`iat`/`nbf` in JWTs (as seconds), and for most database `timestamptz` values internally. Confusion between seconds and milliseconds is one of the most common production bugs in APIs. This converter makes the unit visible and shows the instant in several time zones without sending the value to a server.
Seconds vs milliseconds
A contemporary second timestamp is 10 digits (around 1.7e9). JavaScript `Date.now()` is 13 digits. If you store `Date.now()` in a JWT `exp` field, RFC 7519 verifiers will treat it as a year in the 50-million range and the token will look absurd here. APIs should document the unit. PureDevKit guesses: values with absolute magnitude ≥ 1e12 are treated as milliseconds. You can override when a historical millisecond timestamp is small or a far-future second timestamp is large.
Time zones are display, not storage
The instant is the same worldwide; zones only change the wall clock. Store UTC (or a timezone-aware type) in databases. Convert to a zone at the edge for UI. India Standard Time (`Asia/Kolkata`) is UTC+05:30 with no DST. US zones change with daylight saving. `Intl.DateTimeFormat` with an IANA name is the correct browser API; offset strings like `GMT+530` are harder to keep correct.
ISO-8601 and RFC 3339
`Date.toISOString()` emits RFC 3339 UTC with milliseconds and a `Z` suffix, which is the best interchange form. Offsets like `2026-08-26T15:38:00+05:30` are also fine. Avoid `MM/DD/YYYY` in APIs. When parsing user input, prefer an explicit timezone; naive local datetimes are ambiguous around DST transitions.
JWT NumericDate
RFC 7519 claims `exp`, `nbf`, and `iat` are NumericDate: seconds since epoch. The JWT debugger on PureDevKit uses the same definition. Convert a human expiry (`2030-01-01T00:00:00Z`) to seconds here, then put that integer in the payload.
Code examples
JavaScript
Math.floor(Date.now() / 1000); // seconds
new Date(seconds * 1000).toISOString();Python
import datetime
datetime.datetime.now(datetime.timezone.utc).timestamp()SQL
SELECT EXTRACT(EPOCH FROM now()); -- Postgres seconds
SELECT UNIX_TIMESTAMP(); -- MySQL seconds