We use cookies and similar technologies to enhance your browsing experience, analyze site traffic, and personalize content and ads. By clicking "Accept", you consent to our use of cookies. Learn more in our Privacy Policy.
by Cosmovex
Convert Unix epoch timestamps to human-readable dates in any timezone. Supports UTC, ISO 8601, RFC 2822, relative time. Batch convert multiple timestamps, calculate date expressions, and convert dates back to timestamps. No signup required.
A Unix timestamp is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970, ignoring leap seconds. It's the format most databases, APIs, and log files use to store a moment in time, because a single integer is unambiguous across time zones. The problem is that an integer like 1717286400 means nothing to a human reading it. This tool converts in both directions: paste an epoch value to see the human-readable date in your local time and in UTC, or pick a date to get the matching timestamp.
Everything runs in your browser. The timestamp you paste, the dates you generate, and the conversions in between never leave your device, so it's safe to drop in values from production logs or internal systems. It handles seconds and milliseconds, shows both local and UTC output side by side, and updates as you type so you can sanity-check a value without round-tripping through a script or a database query.
Paste a number and the tool detects whether it's in seconds or milliseconds by its magnitude (10-digit values are seconds, 13-digit values are milliseconds) and converts accordingly. You get four readings at once:
3 hours ago)2024-06-02T00:00:00Z) for copying into code or ticketsGoing the other way, pick a date and time and the tool emits the matching epoch value in both seconds and milliseconds. There's no rounding surprise: if you enter milliseconds, the millisecond field stays exact rather than getting truncated to whole seconds. Because the conversion happens locally, you can convert thousands of values in a session without any rate limits or network round-trips.
Say a log line shows 1717286400. That's 10 digits, so it's seconds. Converting gives:
2024-06-02 00:00:002024-06-02T00:00:00ZIf your machine is set to America/New_York (UTC-4 in June), the same instant reads as 2024-06-01 20:00:00 locally. Same moment, different wall clock.
Now the millisecond version: 1717286400000 is 13 digits. It points to the exact same instant, just with thousandths-of-a-second resolution. A common bug is passing a millisecond value to something expecting seconds, which lands you in the year 56380. If a converted date looks absurdly far in the future, you almost certainly mixed up the unit. The quick mental check: a current seconds timestamp is 10 digits; a current milliseconds timestamp is 13.
created_at or ts as an epoch integer. Paste it here to find out when an event happened without writing a one-off script.exp and iat claims, OAuth token expiry, rate-limit reset headers, and webhook payloads are almost always epoch values. Convert to confirm a token really is expired or that a Retry-After time is what you expect.now().BIGINT timestamp before running a query, or build the integer you need for a WHERE created_at > ? filter.2024-06-02T00:00:00Z is unambiguous and 1717286400 is not.Seconds vs. milliseconds is the number-one mistake. JavaScript's Date.now() returns milliseconds; most backends (Python's time.time() truncated, PostgreSQL EXTRACT(EPOCH ...), Unix date +%s) return seconds. Pass the wrong one and your date is off by a factor of 1000.
Time zones are a display concern, not a storage concern. The epoch value itself is always UTC-based. The local time you see depends on your browser's zone, which is why the same number shows differently on two machines. When in doubt, trust the UTC column.
Leap seconds don't exist in Unix time. The format treats every day as exactly 86,400 seconds, so it silently skips the handful of leap seconds added since 1972. For anything other than astronomy this is fine and is what you want.
Watch the boundaries. Negative timestamps are valid and represent dates before 1970. Very small values like 0 map to the epoch itself (1970-01-01T00:00:00Z), not to "no date."
The 1970 epoch comes from early Unix, where engineers needed a fixed reference point and picked the start of the decade they were working in. It stuck, and now nearly every system agrees on it.
The catch is storage size. A signed 32-bit integer can hold values up to 2,147,483,647 seconds, which runs out on 2038-01-19 at 03:14:07 UTC. One second later, a 32-bit counter overflows to a large negative number and wraps back to December 1901. This is the Year 2038 problem, and it affects any system still using 32-bit time_t.
The fix is moving to 64-bit timestamps, which push the limit roughly 292 billion years out. Most modern languages and 64-bit operating systems already use 64-bit time, so you'll mainly meet this in legacy code, embedded devices, and old database columns. If you store epoch values, use a 64-bit type (BIGINT, int64) and you never have to think about it again.
It's the number of seconds since 00:00:00 UTC on January 1, 1970, with leap seconds ignored. Because it's a single UTC-based integer, it represents one exact moment in time regardless of where it's read.
Count the digits. A present-day timestamp in seconds is 10 digits; in milliseconds it's 13. This tool detects the unit by magnitude, but checking the digit count yourself is a reliable habit.
The epoch value is always UTC, but the local reading is rendered in each browser's configured time zone. The instant is identical; only the wall-clock display differs. Compare the UTC column to confirm.
Yes. Negative values represent dates before the 1970 epoch. For example, -86400 is 1969-12-31T00:00:00Z. The tool handles these the same as any other value.
A 32-bit signed integer overflows on 2038-01-19 03:14:07 UTC and wraps to a negative number, breaking date math on legacy systems. Using 64-bit timestamps avoids it entirely.
In JavaScript use `Math.floor(Date.now() / 1000)` for seconds (Date.now() alone gives milliseconds). In Python use `int(time.time())`. On the command line, `date +%s` returns seconds.
No. The conversion runs entirely in your browser, so timestamps and dates from logs or internal systems stay on your device and aren't sent to any server.
By definition every day is treated as exactly 86,400 seconds, which keeps the arithmetic simple. The trade-off is that the handful of leap seconds added since 1972 aren't represented, which is acceptable for almost all software.