Unix Timestamp Explained: How to Convert Unix Time

Logs, databases and API responses often store time as a bare number such as 1760000000. It isn’t obvious that this is 9 October 2025 at 08:53:20 UTC, but it follows a simple rule, and most conversion bugs come from one of two mix-ups: seconds versus milliseconds, and UTC versus local time.

What is Unix time?

Unix time counts the seconds since the Unix epoch: 1 January 1970 at 00:00:00 UTC. Timestamp 0 is that moment, 86400 is exactly one day later, and negative numbers are dates before 1970. Every day counts as exactly 86,400 seconds, so leap seconds are left out, as the POSIX standard’s definition of seconds since the epoch specifies.

date = 1970-01-01 00:00:00 UTC + timestamp seconds

The big advantage is that a timestamp is the same everywhere. It names one instant, with no time zone, no daylight saving time and no date format to misread. Only when you display it do you pick a time zone.

That keeps the arithmetic simple: one day is always 86,400 seconds, and one week 604,800.

Is my timestamp in seconds or milliseconds?

Timestamps in seconds have had 10 digits since September 2001 and will until the year 2286. Mixing up the units is the most common timestamp bug: read as seconds, the millisecond timestamp above lands tens of thousands of years in the future, and read as milliseconds, 1760000000 becomes 21 January 1970. To convert, multiply seconds by 1000, or divide milliseconds by 1000.

Using the converter

In the Unix timestamp converter, choose seconds or milliseconds and enter the timestamp; if the number of digits suggests the other unit, you’re told. To go the other way, enter a date and time under “Date → timestamp” and say whether it’s local time or UTC. The same clock time is a different instant in each time zone, so this choice matters.

Why does one timestamp show different local times?

1767225600 is 1 January 2026 at 00:00 UTC. In Pakistan (UTC+5) that’s 05:00 on 1 January; in New York (UTC−5 in winter) it’s 19:00 on 31 December 2025. Same timestamp, same instant, three different calendar readings. Store the timestamp, and convert to local time only when you show it to someone.

Converting in code

JavaScript

// Timestamp (seconds) to date
new Date(1760000000 * 1000).toISOString(); // "2025-10-09T08:53:20.000Z"

// Current time in seconds
Math.floor(Date.now() / 1000);

// A UTC date to seconds (months start at 0: January is 0)
Date.UTC(2026, 0, 1) / 1000; // 1767225600

Python

from datetime import datetime, timezone

datetime.fromtimestamp(1760000000, tz=timezone.utc)  # 2025-10-09 08:53:20+00:00
int(datetime(2026, 1, 1, tzinfo=timezone.utc).timestamp())  # 1767225600

Command line and SQL

• Linux: date -u -d @1760000000
• macOS: date -u -r 1760000000
• PostgreSQL: to_timestamp(1760000000)
• MySQL: FROM_UNIXTIME(1760000000), shown in the session’s time zone

Common mistakes

• Mixing seconds and milliseconds, which gives dates in 1970 or far in the future. Check the number of digits.
• Parsing dates without a time zone. In JavaScript, new Date("2026-01-01") is read as UTC, but new Date("2026-01-01T00:00") is read as local time. Add Z or an offset such as +05:00 to be explicit.
• Forgetting that JavaScript months start at 0, so Date.UTC(2026, 1, 1) is 1 February.
• Storing local times instead of timestamps, which become ambiguous when clocks change for daylight saving time.
• Using 32-bit integers. A signed 32-bit number can’t go beyond 2147483647, which is 19 January 2038 at 03:14:07 UTC. Use 64-bit values for timestamps.

To count the days between two dates rather than convert an instant, use the date difference calculator.