Unix Timestamp Converter

A Unix timestamp (also called Unix time, epoch time, or POSIX time) is the total number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — known as the Unix epoch. It is a single integer that uniquely identifies any moment in time, independent of timezone or locale. Example: 1748000000 represents a specific moment in 2025. Negative timestamps represent dates before January 1, 1970. Unix timestamps are used universally in computing, databases, APIs, and log files because they are compact, sortable, and unambiguous.

Unix time in seconds is a 10-digit integer (as of 2001, growing to 11 digits in 2286). Unix time in milliseconds is a 13-digit integer (seconds × 1000). JavaScript's Date.now() returns milliseconds. Python's time.time() returns seconds as a float. Java's System.currentTimeMillis() returns milliseconds. Most Unix system calls and databases use seconds. When you see a number around 1,700,000,000 it is seconds; around 1,700,000,000,000 it is milliseconds. This converter auto-detects which format you entered based on digit count.

The Unix epoch was chosen when Unix was developed at Bell Labs in the late 1960s and early 1970s. It was simply a convenient recent reference point. Different systems use different epochs: Microsoft FILETIME starts from January 1, 1601. GPS time starts from January 6, 1980. Excel dates start from January 1, 1900. The epoch has no special astronomical or historical significance — it was a practical choice made by engineers who needed a shared reference point for time calculations.

The Y2K38 problem affects systems that store Unix timestamps as a signed 32-bit integer. The maximum value of a signed 32-bit integer is 2,147,483,647, which corresponds to January 19, 2038 at 03:14:07 UTC. After that moment, the timestamp overflows to a large negative number, representing December 13, 1901. Modern 64-bit systems are not affected — a 64-bit timestamp can represent dates billions of years in the future. Legacy embedded systems, older databases, and some 32-bit software may still be vulnerable. Use the "Y2K38" button above to see the overflow timestamp.

JavaScript uses milliseconds natively. To convert seconds to a Date object: new Date(timestamp * 1000). To get the current timestamp in seconds: Math.floor(Date.now() / 1000). In milliseconds: Date.now(). To format as ISO string: new Date(ts * 1000).toISOString() returns "2025-05-15T12:00:00.000Z". To convert a date string to a Unix timestamp in seconds: Math.floor(new Date('2025-05-15T12:00:00Z').getTime() / 1000). Always be explicit about UTC vs local time to avoid timezone bugs.

Python: import datetime, then datetime.datetime.fromtimestamp(1748000000) for local time or datetime.datetime.utcfromtimestamp(1748000000) for UTC. In Python 3.3+, use datetime.datetime.fromtimestamp(ts, tz=datetime.timezone.utc) for timezone-aware objects. To get the current Unix timestamp: import time; int(time.time()). To convert a datetime to a timestamp: dt.timestamp() in Python 3.3+. Always prefer timezone-aware datetimes to avoid DST and locale bugs in production code.

ISO 8601 is the international standard for date and time representation. Format: YYYY-MM-DDTHH:MM:SS.sssZ where T separates date from time and Z means UTC. Example: 2025-05-15T12:00:00.000Z. This is the format returned by JavaScript's date.toISOString() and is widely used in JSON APIs. Unix timestamps and ISO 8601 represent the same information differently: a Unix timestamp is a compact integer ideal for computation; ISO 8601 is human-readable and locale-independent. Most programming languages convert between them in one line.

Key Unix timestamps worth knowing: 0 = January 1, 1970 00:00:00 UTC (the Epoch). 1,000,000,000 = September 9, 2001 (Unix users celebrated "1 billion seconds"). 1,234,567,890 = February 13, 2009 (another milestone celebrated online). 1,500,000,000 = July 14, 2017. 2,000,000,000 = May 18, 2033. 2,147,483,647 = January 19, 2038 03:14:07 UTC (Y2K38 for signed 32-bit systems). For milliseconds, multiply each value by 1,000. The current timestamp is shown live at the top of this page.

No. Unix time ignores leap seconds. Leap seconds are occasional 1-second adjustments added to UTC by the IERS to account for Earth's irregular rotation. When a leap second occurs, Unix time "stands still" for one second — the same Unix second value repeats. This means Unix time is not a true count of elapsed SI seconds. For most applications this is irrelevant. For high-precision scientific computing, TAI (International Atomic Time) or GPS time is used instead. The IERS voted to discontinue leap seconds by 2035.

MySQL has TIMESTAMP (stores Unix seconds, limited to 2038) and DATETIME (calendar date, up to year 9999). PostgreSQL stores timestamps as UTC internally. SQLite stores them as integer, real, or text — integer Unix seconds is most common. MongoDB uses BSON Date in milliseconds. Redis uses Unix seconds for key expiry (TTL). Best practice: always store in UTC; use BIGINT for milliseconds to avoid Y2K38; index timestamp columns for range queries. Normalize all log timestamps to UTC Unix seconds before comparing across systems to avoid timezone mismatches.