Unix Timestamp Converter
Convert epoch seconds, milliseconds, microseconds and nanoseconds to a date in any timezone and back, with BigInt precision so nanosecond values are never rounded.
Timestamp or date
Enter an epoch number or a date string to convert it.
Current time
Conversion uses your browser's own Intl timezone database, so daylight saving is applied correctly for the instant you entered. Nothing is sent to a server.
About the Unix Timestamp Converter
Paste a Unix timestamp and read it back as a date in any timezone — or go the other way and get epoch seconds, milliseconds, microseconds and nanoseconds from a date string. The unit is detected from the number's magnitude, so you do not have to know in advance whether a log line is in seconds or milliseconds.
A Unix timestamp counts the seconds since 1970-01-01T00:00:00Z, and its whole appeal is that it has no timezone: the same instant is the same number everywhere. Timezones only enter when you display it, which is why the conversion is done here with your browser's own IANA database rather than a fixed offset. That distinction matters — an offset like UTC-5 is only correct for part of the year in most of North America and Europe.
Nanosecond output is computed with BigInt rather than ordinary arithmetic. A nanosecond timestamp today is around 1.7 × 10^18, comfortably past the largest integer a JavaScript number can hold exactly, and a naive multiplication quietly rounds the last few digits.
- Unit auto-detected from digit count — seconds, milliseconds, microseconds or nanoseconds
- Any IANA timezone, with daylight saving applied for that specific instant
- ISO 8601 in UTC and with a zone offset, plus the RFC 7231 form HTTP headers use
- Relative time, ISO week number and day of year
- Live clock you can capture with one click
How to use it
- Paste an epoch number, or a date string such as 2026-07-25T12:00:00Z.
- Leave Unit on Auto-detect unless the value is ambiguous — a small number that really is milliseconds, for example.
- Pick a timezone. It defaults to your own; UTC and the common zones are in the list.
- Read the conversions table and copy the format you need.
- Press Now to capture the current time, or Use to load the live clock into the input.
Real-world use cases
Backend developers
Convert an epoch value from a log line, a JWT exp claim, or an API response into a readable date without writing a throwaway script.
DevOps & SRE
Read epoch timestamps from logs and metrics in the timezone that matters during an incident, and check what a value looks like across several regions at once.
QA & test engineers
Construct a specific epoch or ISO 8601 value to feed into a test fixture or an API request, including deliberately awkward ones like a leap-day date or a value just before 2038.
Data engineers
Check whether a column of timestamp values is seconds, milliseconds, microseconds or nanoseconds before writing an ingestion job that assumes the wrong one.
Frontend developers
Check how a stored timestamp renders across IANA timezones and daylight-saving boundaries before shipping a date display to users in multiple regions.
Examples
Seconds to a readable date
1774440000
2026-03-25T12:00:00.000Z Wednesday, March 25, 2026 at 12:00:00 PM UTC
Ten digits, so it is read as seconds. This is the form most APIs, JWT claims and cron logs use.
The same instant in milliseconds
1774440000000
2026-03-25T12:00:00.000Z
Thirteen digits. JavaScript's Date.now(), Java's System.currentTimeMillis() and most log aggregators emit this form.
A date string back to epoch
2026-07-25T12:00:00Z
seconds 1785024000 milliseconds 1785024000000 microseconds 1785024000000000 nanoseconds 1785024000000000000
Below milliseconds the extra digits are zeros — a JavaScript Date has no finer resolution, and inventing digits would be worse than padding them.
One instant, three zones
1785024000
UTC 2026-07-25T12:00:00+00:00 Asia/Tokyo 2026-07-25T21:00:00+09:00 Asia/Kolkata 2026-07-25T17:30:00+05:30
Same timestamp, same instant — only the wall-clock rendering differs. Kolkata is one of several zones on a half-hour offset.
Common errors
| Message | Cause | Fix |
|---|---|---|
| Date shows as 1970-01-21 or similar | A millisecond timestamp was read as seconds. Dividing 1.7 × 10^12 by the wrong factor lands you a few weeks after the epoch. | Check the digit count: 10 digits is seconds, 13 is milliseconds. Auto-detect handles this, but a hard-coded parser in your own code may not. |
| Date shows as far in the future (year 56000+) | The mirror image — a seconds value passed to something expecting milliseconds, such as the JavaScript Date constructor. | Multiply by 1000 when handing a seconds timestamp to new Date(), or use new Date(seconds * 1000). |
| Time is off by exactly one hour for part of the year | A fixed UTC offset was used instead of a timezone. UTC-5 is New York in winter but not in summer. | Store and convert with an IANA zone name like America/New_York, which carries the daylight-saving rules. |
| Timestamp is off by a few hours after a round trip | A date string without a zone designator was parsed as local time in one place and UTC in another. | Always serialise with an explicit Z or offset. 2026-07-25T12:00:00Z is unambiguous; 2026-07-25 12:00:00 is not. |
| Last digits of a nanosecond timestamp are wrong | The value exceeded Number.MAX_SAFE_INTEGER (about 9 × 10^15) and lost precision in floating-point arithmetic. | Handle nanosecond values as BigInt or as strings. This tool uses BigInt so the digits stay exact. |
| Signed integer overflow in 2038 | A 32-bit signed time_t runs out on 2038-01-19T03:14:07Z, after which it wraps to 1901. | Use a 64-bit time type. Anything you write today should already store 64-bit or millisecond values. |
Frequently asked questions
›Is my timestamp sent to a server?
No. Parsing, timezone conversion and formatting all happen in your browser using the built-in Intl APIs. The live clock reads your own system time. Nothing is transmitted, stored or logged.
›How does auto-detect know the unit?
By digit count. A current timestamp has 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds, and those ranges do not overlap for any date since 2001. If your value is genuinely ambiguous — a small number that really is milliseconds — set the unit explicitly.
›Does a Unix timestamp have a timezone?
No, and that is the point. It counts seconds since 1970-01-01T00:00:00Z, so one instant is one number worldwide. A timezone is only applied when you render it for a human, which is why the same timestamp shows different wall-clock times in the table above.
›Why use an IANA zone name instead of a UTC offset?
An offset is only correct for part of the year in any region that observes daylight saving. America/New_York is UTC-5 in January and UTC-4 in July. Storing the zone name keeps the rules; storing the offset keeps a snapshot that goes wrong twice a year.
›What is the year 2038 problem?
A 32-bit signed integer counting seconds overflows on 2038-01-19T03:14:07Z and wraps around to 1901. Any system still storing time in a 32-bit time_t will need to move to a 64-bit type before then. 64-bit timestamps are good for roughly 292 billion years.
›Can it handle dates before 1970?
Yes. A negative epoch value counts backwards from 1970, so -86400 is 1969-12-31. The supported range is the full range of the JavaScript Date type: roughly ±273,000 years around the epoch.
›Does Unix time account for leap seconds?
No, and that's by definition rather than an omission. POSIX time treats every day as exactly 86,400 seconds, so the 27 leap seconds inserted into UTC since 1972 are not represented in the count at all. When a leap second actually occurs, real systems either repeat a second or smear it across the surrounding hours rather than encoding it in the timestamp — which is why Unix time is sometimes described as tracking UTC only approximately across a leap-second boundary, even though it agrees with it exactly the rest of the time.
›Why does the relative time say "2 hours ago" instead of an exact duration?
It's rounded to the nearest sensible unit on purpose, using the same thresholds a person would use narrating a clock: seconds under 45 seconds, minutes up to 45 minutes, hours up to 22 hours, then days, months and years. It's meant to be read at a glance, not measured — for an exact duration, subtract the epoch millisecond values in the conversions table instead.
Last updated