Epoch & Unix Timestamp Converter
The current epoch time, live, with conversion both ways: any Unix timestamp to a human-readable date, and any date back to a timestamp.
Current Unix time
—
Convert epoch time to a human-readable date and back
Works with Unix timestamps in seconds, milliseconds, microseconds and nanoseconds.
Assuming this timestamp is in
- UTC
- —
- Local time
- —
- Relative
- —
- Unix timestamp
- —
- Milliseconds
- —
- UTC
- —
- Local time
- —
Timestamp to date
Date to timestamp
Unix timestamps in JavaScript, Python, SQL and other languages
Reading the current epoch time, or turning a timestamp into a date, is a one-liner almost everywhere. Every call below works in seconds, and every conversion gives UTC except MySQL's FROM_UNIXTIME and PostgreSQL's to_timestamp, which display in the session time zone. For milliseconds, JavaScript's Date.now() returns them directly; elsewhere, multiply by 1,000.
| Language | Current Unix timestamp | Timestamp to date |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | new Date(1789491765 * 1000).toISOString() |
| Python | int(time.time()) | datetime.fromtimestamp(1789491765, tz=timezone.utc) |
| Java | Instant.now().getEpochSecond() | Instant.ofEpochSecond(1789491765) |
| C# / .NET | DateTimeOffset.UtcNow.ToUnixTimeSeconds() | DateTimeOffset.FromUnixTimeSeconds(1789491765) |
| Go | time.Now().Unix() | time.Unix(1789491765, 0).UTC() |
| PHP | time() | gmdate('Y-m-d H:i:s', 1789491765) |
| Ruby | Time.now.to_i | Time.at(1789491765).utc |
| Swift | Int(Date().timeIntervalSince1970) | Date(timeIntervalSince1970: 1789491765) |
| MySQL | SELECT UNIX_TIMESTAMP(); | SELECT FROM_UNIXTIME(1789491765); |
| PostgreSQL | SELECT floor(extract(epoch FROM now()))::bigint; | SELECT to_timestamp(1789491765); |
| SQLite | SELECT strftime('%s', 'now'); | SELECT datetime(1789491765, 'unixepoch'); |
| SQL Server | SELECT DATEDIFF_BIG(SECOND, '1970-01-01', SYSUTCDATETIME()); | SELECT DATEADD(SECOND, 1789491765, '1970-01-01'); |
| Bash (GNU date) | date +%s | date -u -d @1789491765 |
| macOS (BSD date) | date +%s | date -u -r 1789491765 |
| PowerShell | [DateTimeOffset]::UtcNow.ToUnixTimeSeconds() | [DateTimeOffset]::FromUnixTimeSeconds(1789491765).UtcDateTime |
How it works
Unix time, also called epoch time or POSIX time, is a single integer: the number of seconds that have elapsed since midnight UTC on 1 January 1970, known as the Unix epoch. Because it is one number with no zone, no formatting and no locale, it is unambiguous everywhere, which is why logs, databases, APIs and file systems store it.
Paste a timestamp and the converter first reads it as an exact integer, so a 19-digit nanosecond value keeps every digit instead of being rounded the way a JavaScript number would round it. It then works out the unit from the length of the number and tells you what it decided in a sentence you can correct. Mixing up seconds and milliseconds is the commonest epoch bug there is, and a guess you can see is far easier to catch than one made silently.
| Unit | Digits today | 15 September 2026, 17:02:45 UTC |
|---|---|---|
| Seconds | 10 | 1789491765 |
| Milliseconds | 13 | 1789491765000 |
| Microseconds | 16 | 1789491765000000 |
| Nanoseconds | 19 | 1789491765000000000 |
The result is the same instant written three ways: in UTC, in your own time zone with its current offset, and relative to now, counting forwards or back. Any fraction of a second the input carried is shown to its full precision rather than cut to milliseconds.
Going the other way, type a year, month, day and time and choose UTC or local time. A clock reading only becomes an instant once a zone is attached: 09:00 in UTC and 09:00 in Delhi are five and a half hours apart. Local conversions follow your device's time-zone rules for that date, so a date on the far side of a daylight saving change gets the offset in force then, and a time that never happened because the clocks sprang forward is moved on by the length of the jump, as calendar software does.
Examples
Reading a timestamp from a database or a log. 1789491765 is seconds since 1 January 1970 UTC. Paste it in and you get Tuesday 15 September 2026 at 17:02:45 UTC, the same moment in your own zone, and how long ago it was, which is usually what you actually wanted when debugging.
Spotting a milliseconds value. A thirteen-digit number such as 1789491765000 is milliseconds. Read as seconds it lands in the year 58,676, a distinctive enough error to recognise once you have seen it. Because the converter names the unit it detected, the mix-up shows on screen instead of hiding in a wrong date.
Checking when a token expires. The exp and iat claims in a JSON Web Token are Unix seconds. Paste the exp value to see exactly when the token stops being accepted, in UTC and in your local time, and how far away that is.
Nanoseconds from Go or a tracing system. Go's time.Now().UnixNano() and many metrics and tracing tools emit 19-digit nanosecond values. They are too long for a JavaScript number to hold exactly, so the converter reads them as integers and shows all nine fractional digits.
Generating a value for a test fixture. Enter a date, choose UTC and take the timestamp, for a fixture that does not depend on the machine's locale or time zone.
Practical notes
The live counter reads your device clock, so it is exactly as accurate as that clock and no more. A computer or phone that synchronises with a time server is normally within a fraction of a second; one that does not can drift by minutes over months.
Unix time counts seconds since the epoch and deliberately ignores leap seconds, which means it is not a true count of elapsed physical seconds. When a leap second occurs the same value is used twice. This is a feature rather than a bug: it keeps the arithmetic simple and keeps every day exactly 86,400 seconds long.
A browser date holds whole milliseconds, so microsecond and nanosecond digits are carried beside it for display rather than used in date arithmetic. The usable range is the one every JavaScript date shares, about 273,000 years either side of 1970, which is far beyond anything a real timestamp needs.
Negative values represent dates before 1970 and are valid, though some software rejects them. A signed 32-bit counter overflows on 19 January 2038. Modern systems use 64-bit values and are unaffected, but embedded devices and old file formats are still out there, and dates beyond 2038 are a reasonable thing to test against.
Frequently asked questions
What is a Unix timestamp?
A Unix timestamp, also called epoch time or POSIX time, is the number of seconds since 00:00:00 UTC on 1 January 1970, not counting leap seconds. 1789491765, for example, is Tuesday 15 September 2026 at 17:02:45 UTC.
How do I convert a Unix timestamp to a human-readable date?
Paste it into the box at the top of this page and press Timestamp to readable date. You get the date and time in UTC, the same moment in your own time zone, and how long ago or how far ahead it is. In code it is a one-liner in most languages; the table above lists them.
How do I convert a date to a Unix timestamp?
Type the year, month, day and time into the row below the timestamp box, choose UTC or your local time, and press Date to timestamp. The zone matters: the same clock time is a different instant, and so a different timestamp, in every time zone.
Is my timestamp in seconds, milliseconds, microseconds or nanoseconds?
Count the digits. For dates between 2001 and 2286 a timestamp has 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds. The converter detects the unit the same way, says what it assumed, and lets you change it when a small value was guessed wrong.
Why does my timestamp convert to a date thousands of years away?
A milliseconds value is being read as seconds. 1789491765000 taken as seconds falls in the year 58,676; divided by 1,000 it is 15 September 2026. The opposite mistake, seconds read as milliseconds, lands in January 1970.
Is a Unix timestamp the same in every time zone?
Yes. A timestamp counts from one fixed instant, so 1789491765 is the same moment in Tokyo and in Toronto. Time zones only come in when the number is shown as a local date and clock time, which is why the converter puts UTC and your local time side by side.
What is the current Unix timestamp?
It is the number ticking at the top of this page, in seconds and in milliseconds, with the same instant in ISO 8601 beside it. It is read from your device clock, so it is as accurate as that clock is.
How do I convert a Unix timestamp in Excel or Google Sheets?
With a seconds timestamp in cell A1, =A1/86400+DATE(1970,1,1) gives the date and time in UTC; format the cell as a date. For milliseconds, divide by 86,400,000 instead, and add your UTC offset in hours divided by 24 to show local time.
Does Unix time count leap seconds?
No. Unix time treats every day as exactly 86,400 seconds, so a leap second reuses a value instead of adding one. That keeps conversion to simple arithmetic, at the cost of drifting from atomic time by every leap second added since 1972.
What is the year 2038 problem?
Software that stores Unix time in a signed 32-bit integer runs out at 2147483647, which is 03:14:07 UTC on 19 January 2038; one second later the value wraps round to December 1901. Modern platforms use 64-bit time and are unaffected, but embedded devices and old file formats may not be.
Can a Unix timestamp be negative?
Yes. Dates before 1970 are negative: -86400 is 31 December 1969 at 00:00 UTC. The converter handles them, but some databases and libraries reject negative values, so test before relying on them.
Guides on this topic
- What Unix time is, and what it is not What a Unix timestamp counts, why it is the same in every time zone, how leap seconds and milliseconds fit in, and where 32-bit systems run out.
- The year 2038 problem What happens at 03:14:07 UTC on 19 January 2038, which systems are still exposed, how the fix works, and why the problem shows up long before the date itself.
- How to store dates and times correctly When to store UTC, when to store local time with a zone name, why offsets alone are not enough, which database types to use, and the parsing traps in JavaScript.