Timestamp Converter
Convert Unix timestamps and dates across formats and time zones, and explain a cron expression.
Related tools
- UUID GeneratorGenerate UUID v1, v3, v4, v5, v7 and ULID identifiers and decode existing UUIDs.
- JSON ToolsFormat, minify, repair and validate JSON with exact error positions, browse it as a tree, and convert between JSON, CSV and YAML.
- Encoder / DecoderEncode and decode Base64, URLs and HTML entities, and convert number bases.
About this tool
Timestamp Converter takes a Unix timestamp or a date string and shows the same instant as Unix seconds, Unix milliseconds, ISO 8601 in UTC, an RFC 2822 / HTTP date, a relative phrase and the weekday with its ISO week number, plus a table of nine time zones alongside your own. The unit of a bare number is inferred from its digits: up to 11 is read as seconds, up to 14 as milliseconds, up to 17 as microseconds and anything longer as nanoseconds. Anything that is not a bare number goes to the browser's own date parser, and an empty box or the word “now” means the current time, read from your device clock rather than from a server. It converts one instant at a time - there is no date arithmetic, no custom format string and no duration calculator. A second mode on the same page explains a cron expression: it reads standard (Vixie) cron with five fields, or six when the first is seconds, plus ranges, lists, steps, three-letter day and month names, the @hourly to @yearly aliases and both 0 and 7 for Sunday, states in plain English when the schedule fires, and lists the next five runs in your browser's time zone and in UTC. The Quartz extensions L, W and # are named and refused rather than guessed at, and an expression that can never fire - 31 February, say - is reported as such instead of being given five invented dates.
The conversion is pure browser work: the standard Date object for parsing and the Unix and UTC output, Intl.DateTimeFormat for the time-zone table, Intl.RelativeTimeFormat for the relative phrase, and no Web Crypto and no network request of any kind. Nothing is sent to the XGM API. The only things written into the URL are the value you typed, in the q parameter, and the mode switch above, in the mode parameter, so a copied link reopens the same conversion - that is deliberate for a timestamp, which is not a secret, and no other tool on this page behaves that way with sensitive input.
How to use it
- Open the Timestamp Converter tool.
- Paste or type the input you want to inspect.
- Read the result, which is computed in your browser; the input is not sent to XGM.
- Copy the output only after checking it looks correct.
- Use related XGM tools if you need a broader diagnostic view.
FAQ
How does it decide whether my number is seconds or milliseconds?
By counting the digits before any decimal point: 11 or fewer is seconds, 12 to 14 is milliseconds, 15 to 17 is microseconds and more than that is nanoseconds. So 1700000000 becomes November 2023 and 1700000000000 the same instant in milliseconds. The detected unit is printed above the result, which is the quickest way to spot a value that was pasted in the wrong scale.
Are leap seconds taken into account?
No, and no Unix timestamp has them. POSIX time treats every day as exactly 86400 seconds, and the time value the browser works with does the same, so an instant such as 2016-12-31T23:59:60Z has no representation here. If you need true elapsed SI seconds between two distant dates, the result is short by however many leap seconds were inserted in between.
Does the time-zone table follow daylight saving time?
Yes. Each row is formatted with the browser's Intl date formatter using IANA zone identifiers, so the UTC offset applied is the one in force at the instant being converted, not the zone's current offset. The “Example: DST change” button loads 2026-03-29T01:30:00Z, the morning the European Union clocks move, which shows the same instant landing on different local clock readings. The first row is the zone your browser reports for you.
Is the ISO row the same thing as RFC 3339?
The ISO 8601 row is always UTC, always with milliseconds and a trailing Z, and that form is a valid RFC 3339 timestamp, which is the profile most APIs and log formats mean when they say ISO. RFC 3339 also permits a numeric offset such as +02:00; this tool always normalises to Z instead. The row below it is the RFC 2822 style date that HTTP uses in Date and Expires headers.
Why does the current time here differ from my server's?
The clock comes from the device you are using and ticks once a second in the page; XGM never supplies a time. A drifting laptop clock therefore shifts every relative figure on the page, and it is a common reason for tokens that look expired locally but not on the server. Compare against the Date response header of a known host - the HTTP Headers tool shows it - before assuming a timestamp is wrong.