What is a Unix timestamp?

A Unix timestamp is the number of seconds since midnight UTC on January 1, 1970, not counting leap seconds. It is also called epoch time or POSIX time. As of September 2026 the value is about 1.79 billion.

How do I convert a Unix timestamp to a date in JavaScript?

Pass the timestamp in milliseconds to the Date constructor: new Date(timestamp * 1000). Use .toISOString() for UTC, or .toLocaleString('en-US', { timeZone: 'America/New_York' }) for a specific zone. JavaScript uses milliseconds, so multiply seconds by 1000.

Is a Unix timestamp in seconds or milliseconds?

The classic Unix timestamp is in seconds. JavaScript's Date uses milliseconds, Java's Instant uses nanoseconds, and some APIs use microseconds. A 10-digit value around 1.7 billion is seconds, 13 digits is milliseconds, and 19 digits is nanoseconds.

What time zone is a Unix timestamp in?

UTC, always. The timestamp counts seconds since the UTC epoch, so it has no offset or zone attached. To display it locally, convert to UTC first and then shift to the target IANA zone, such as Europe/Berlin or America/New_York.

What happens to Unix time in 2038?

On January 19, 2038 at 03:14:07 UTC, a 32-bit signed integer storing Unix seconds overflows and wraps to a date in 1901. Systems using 64-bit time_t are unaffected. The fix for at-risk 32-bit systems is to migrate to 64-bit time_t before that date.

How do I get the current Unix timestamp?

In JavaScript, Math.floor(Date.now() / 1000) gives seconds. In Python, int(time.time()). In the shell, date +%s. All return the seconds since the UTC epoch at the moment of the call.

How Do I Convert a Unix Timestamp to a Readable Date?

Q: Does Unix time count leap seconds?

No. Unix time ignores leap seconds, so every day is treated as exactly 86,400 seconds. Real UTC can differ from Unix time by up to 0.9 seconds, and by the full count of historical leap seconds if you compare against a clock that does count them. Most systems smear the leap second instead of inserting it.

A Unix timestamp is the number of seconds that have passed since midnight UTC on January 1, 1970, not counting leap seconds. As of September 2, 2026, the current Unix time is about 1,788,393,600. Every modern operating system and programming language can read it, which is why it shows up in logs, databases, APIs, and file metadata.

Converting it to a readable date comes down to one rule: the timestamp is always in UTC, so you convert to UTC first, then shift to the local zone you want to display. Get the zone wrong and the answer is off by hours even though the math is right.

Convert a timestamp in JavaScript

JavaScript's Date constructor takes milliseconds, not seconds, so multiply by 1000. To display the result in a specific zone, use the toLocaleString method with the IANA zone identifier. This prints 2026-09-02 in New York local time for that timestamp.

new Date(1788393600 * 1000) gives the UTC instant
.toLocaleString('en-US', { timeZone: 'America/New_York' }) prints it in New York time
.toLocaleString('en-GB', { timeZone: 'Europe/London' }) prints it in London time
.toISOString() prints the UTC form, 2026-09-02T00:00:00.000Z

A developer in Berlin debugging a webhook log sees the timestamp 1788451200. She runs new Date(1788451200 * 1000).toISOString() in the console and gets 2026-09-02T16:00:00.000Z, which is 18:00 CEST in Berlin. The webhook fired at 6 PM her time, matching the customer report.

Convert a timestamp in Python

Python's datetime module has a fromtimestamp function that takes seconds. By default it returns local time, which is a common source of bugs when code runs on a server in a different zone than the developer. Use datetime.fromtimestamp(ts, tz=timezone.utc) to be explicit, then convert with astimezone.

datetime.fromtimestamp(1788393600, tz=timezone.utc) returns 2026-09-02 00:00 UTC
.astimezone(ZoneInfo('America/New_York')) shifts it to 2026-09-01 20:00 EDT
int(dt.timestamp()) converts a datetime back to a Unix timestamp in seconds

Convert a timestamp in the shell

On Linux and macOS, the date command converts both ways. date -d @1788393600 -u prints the UTC date. date -d @1788393600 prints it in the system's local zone. To go the other way, date -u -d '2026-09-02 00:00:00' +%s returns the timestamp. The @ syntax tells date to read the input as epoch seconds.

A sysadmin in Tokyo checking a rotated log sees files named with timestamps like 1788451200.gz. She runs date -d @1788451200 and gets Thu Sep 3 01:00:00 JST 2026, confirming the log was rotated just after 1 AM local, which matches the nightly cron job.

Seconds, milliseconds, and nanoseconds

The classic Unix timestamp is in seconds. JavaScript uses milliseconds, so a JS timestamp is 1000 times larger. Java's Instant uses nanoseconds. A 13-digit number is milliseconds, a 10-digit number around 1.7 billion is seconds, and a 19-digit number is nanoseconds. Mixing them up is the most common timestamp bug, and it produces dates thousands of years in the future or in 1970.

To check which unit you have, look at the digit count. The value 1788393600000 has 13 digits and is milliseconds, equal to the same instant as 1788393600 in seconds. Divide by 1000 to move from milliseconds to seconds before passing to a tool that expects seconds.

Leap seconds and the UTC gap

Unix time ignores leap seconds. When a positive leap second is inserted, the Unix timestamp repeats a value, and when a negative one would be inserted, it skips. In practice, POSIX clocks smear the leap second across a window instead of inserting it, so most application code never sees a repeated second. The cost of this simplicity is that Unix time and true UTC can differ by up to 0.9 seconds, and by the full count of historical leap seconds (27 so far) if you compare against a clock that does count them.

For logging, scheduling, and display, this gap does not matter. For sub-second scientific timing or legal timestamping, use a representation that carries the leap-second history, such as TAI or a labeled UTC format, instead of raw Unix time.

The 2038 limit

A 32-bit signed integer storing Unix seconds overflows on January 19, 2038 at 03:14:07 UTC. Systems still using 32-bit time_t will wrap to a date in 1901. Most servers and phones shipped after 2010 use 64-bit time_t, which lasts hundreds of billions of years, but embedded devices and old binaries remain a risk. If you maintain a 32-bit system, the fix is to move to 64-bit time_t before 2038, not to patch around the overflow.

The timestamp is always UTC. Convert to UTC first, then to the display zone. Storing local time as a timestamp is the fastest way to produce a bug that only appears for half the year.

Related tools for timestamp work

The Unix Timestamp converter reads and writes epoch seconds, milliseconds, and ISO 8601 strings in one panel. The UTC Time Now page shows the live epoch value alongside the UTC clock. The Time Zone Converter maps a UTC instant to any city. The Discord Timestamp generator formats an epoch value into Discord's relative-time markup.