About Date & Timestamp Converter
Date & Timestamp Converter takes one value — a Unix timestamp in seconds or milliseconds, an ISO 8601 string, or any date string the browser can parse — and shows the same instant six ways at once: ISO 8601, your local zone, UTC, a zone you name, Unix seconds and Unix milliseconds. It also reports which format it thought your input was, which is often the most useful line on the page.
A timestamp is a count of elapsed units since an epoch. It carries no timezone, no calendar and no unit; all three live in an agreement between the systems passing it around, and when that agreement is unwritten it breaks. Two failures dominate: the unit, because seconds and milliseconds differ by a factor of 1000 and a value off by that factor still parses — just into 1970 or into the 58th millennium; and the offset, because a wall-clock string without one means a different instant on every machine that reads it.
How to use this developer tool
- Paste the value into the date or timestamp box. Bare digits are treated as a Unix timestamp; anything else goes to the browser's date parser.
- Set the target timezone. It starts at Asia/Shanghai, but any IANA name works.
- Press Parse and read the detected-format badge first. Unix seconds, Unix milliseconds and ISO 8601 are unambiguous; anything reported as a browser date format went through a fallback whose rules are not standardised.
- Compare the local row against UTC and against your chosen zone. Where the calendar dates differ, that difference is real, and it is where downstream reports go wrong.
- Use Now to drop in the current instant as a reference, then copy the whole block so the next person does not repeat the conversion.
Worked example: one Unix timestamp, six representations
A ten-digit value from a log line, with the target zone set to Asia/Shanghai. Ten digits sit under the seconds/milliseconds cutoff, so it is read as seconds.
1774000000
Asia/ShanghaiDetected format Unix seconds
ISO 8601 2026-03-20T09:46:40.000Z
UTC Friday, March 20, 2026 at 9:46:40 AM UTC
Asia/Shanghai Friday, March 20, 2026 at 5:46:40 PM GMT+8
Unix seconds 1774000000
Unix milliseconds 1774000000000The calendar date happens to match in both zones, which is luck rather than a rule: 09:46 UTC is early enough that adding eight hours does not cross midnight. Run 1700000000 through the same two zones and you get 14 November in UTC but 15 November in Asia/Shanghai — one instant, two dates, and a daily report that disagrees with itself.
Units and formats, side by side
A bare number is read as seconds below 100000000000 and as milliseconds at or above it. That cutoff is a heuristic, not a standard: seconds-since-1970 will not reach eleven digits until the year 5138, while milliseconds passed eleven digits in March 1973.
| Format or unit | Example | How it is read |
|---|---|---|
| Unix seconds | 1774000000 | Under the cutoff, so seconds: 2026-03-20T09:46:40Z |
| Unix milliseconds | 1774000000000 | At or above the cutoff, so milliseconds: the same instant |
| The cutoff itself | 99999999999 vs 100000000000 | The first is seconds and lands in the year 5138; the second is milliseconds and lands on 1973-03-03T09:46:40Z |
| ISO 8601 | 2026-09-21T14:30:00+08:00 | Unambiguous. The standard is broad and also permits basic forms such as 20260921T143000+0800 |
| RFC 3339 | 2026-09-21T14:30:00+08:00 | A strict internet profile of ISO 8601: full date, full time, offset mandatory, Z allowed for UTC |
| RFC 2822 | Mon, 21 Sep 2026 14:30:00 +0800 | Email headers and older tooling. Same instant as the rows above: 2026-09-21T06:30:00Z |
| HTTP-date | Mon, 21 Sep 2026 06:30:00 GMT | The only form allowed in Date and Last-Modified headers, always expressed in GMT |
| Date only | 2026-09-21 | Parsed as UTC midnight: 2026-09-21T00:00:00Z |
| Date and time, no offset | 2026-09-21T14:30:00 | Parsed as local time, so the same text is a different instant in another zone |
Troubleshooting
The result lands in January 1970 or in the year 58185.
Why it happens The unit was wrong by a factor of 1000. Reading 1774000000 as milliseconds gives 1970-01-21T12:46:40Z; reading 1774000000000 as seconds gives 58185-10-27T09:46:40Z.
Fix Count the digits: ten is seconds and thirteen is milliseconds for any date between 2001 and 2286. When you produce a timestamp, name the unit in the field itself — created_at_ms rather than created_at.
A date-only string and a date-time string disagree by a whole day.
Why it happens ECMAScript parses 2026-09-21 as UTC but 2026-09-21T00:00:00 as local time. In Asia/Shanghai the second string is 2026-09-20T16:00:00Z — the previous day.
Fix Never rely on the difference. Append an explicit offset or Z to every date-time you store or transmit, and treat a date-only value as a calendar date rather than an instant.
A string parses here but is rejected, or read differently, somewhere else.
Why it happens Outside ISO 8601, date parsing is implementation-defined. 2026-09-21 14:30:00 with a space works in V8 and fails elsewhere; 09/21/2026 is read as September 21 while 21/09/2026 is Invalid Date; and 2026-09-21T23:59:60Z is rejected outright, because Unix time has no leap seconds.
Fix Treat the detected-format badge as a warning light. If it does not say Unix seconds, Unix milliseconds or ISO 8601, normalise the value to ISO 8601 with an explicit offset before it goes anywhere else.
A wall-clock time near a daylight-saving change converts to something unexpected.
Why it happens An offset-less string is resolved against the local zone, and twice a year that zone has a gap and an overlap. On a machine in America/New_York, 2026-03-08T02:30:00 does not exist and is pushed forward to 07:30Z, while 2026-11-01T01:30:00 exists twice and silently takes the first pass, 05:30Z.
Fix Carry the offset. 2026-11-01T01:30:00-04:00 and 2026-11-01T01:30:00-05:00 are two different instants, and only the offset can tell them apart.
When this tool is the right choice
- Turning a raw timestamp from a log, a database column or a JWT claim into a date you can reason about.
- Checking whether an expiry or a backfill window falls where you think it does in the customer's timezone rather than yours.
- Settling a seconds-versus-milliseconds argument between two services in one paste.
- Producing a correctly formatted ISO 8601 value for a fixture, a query parameter or a bug report.
When to use something else
- Working out when a scheduled job next runs. Describe the schedule in the Cron Expression Parser, which handles recurrence and daylight-saving transitions.
- Measuring elapsed time inside a program. Wall-clock time can jump backwards; use a monotonic clock such as performance.now() or System.nanoTime().
- Calendar arithmetic across months and zones, such as adding one month to 31 January. Use a dated library like Temporal or java.time, which encode those rules.
Privacy and data handling
Everything is computed in this browser tab from the browser's own Intl timezone data. No value is uploaded and nothing persists after the tab closes. Timestamps taken from production logs usually travel with a request id, a user id or an IP address on the same line; paste only the timestamp, because that is all the tool needs.
Related developer tools
Frequently asked questions
How do I tell seconds from milliseconds without counting?
Convert and look at the year. Landing in 1970 means milliseconds were read as seconds; landing thousands of years out means the reverse. The digit count is a shortcut, but the resulting year is the proof.
Why does the Unix seconds row lose my fractional part?
Unix seconds are produced by flooring the millisecond value, so 1774000000.5 shows as 1774000000 while the ISO and millisecond rows keep the .500. Use the millisecond value whenever sub-second precision matters.
Does the year 2038 problem affect me?
A signed 32-bit seconds counter overflows on 2038-01-19T03:14:07Z. This tool uses JavaScript numbers and is unaffected, but a C time_t, an older embedded device or a 32-bit integer column still is. Store timestamps as 64-bit integers or a proper timestamp type.
Should I store UTC or local time?
Store the instant in UTC, and store the zone separately when the local wall clock matters — a meeting at 09:00 Europe/Berlin stays at 09:00 through a daylight-saving change, which a stored UTC instant alone cannot express. Convert to local only for display.
Are negative timestamps supported?
Yes. A negative value is a date before 1970-01-01T00:00:00Z, so -1 is 1969-12-31T23:59:59Z. Many systems that store them still mishandle them in formatting or date arithmetic, so verify the whole path first.
Why does the relative time change on every reload?
Relative labels such as "in 6 months" are computed against the clock at the moment you pressed Parse. They are a presentation aid, not data; store an absolute timestamp and derive the relative form at display time.