Time & Date · Developer Tool

Unix Timestamp Converter

Convert Unix epoch timestamps to human-readable dates and times, or convert any date back to a Unix timestamp. Supports both seconds and milliseconds. Live current timestamp displayed.

Last updated

Live Current Timestamp
Seconds & Milliseconds
Date to Timestamp
UTC & Local Time
Our networkdiscount5Fresh deals. Five at a time.Price drops and coupon codes, ending soonest first.See today’s deals
Current Unix Time: Live
Seconds (Unix / Epoch)
0
Click to copy & load
Milliseconds
0
Click to copy
UTC Date & Time
...
Local: ...
Unix Timestamp Converter
Timestamp ↔ Human-readable date
Auto-detect: 10 digits = seconds · 13 = milliseconds · 16 = microseconds · 19 = nanoseconds

What Is a Unix Timestamp?

A Unix timestamp is the number of seconds since 00:00:00 UTC on January 1, 1970, not counting leap seconds. A 10-digit number is seconds and a 13-digit number is milliseconds: 1,800,000,000 falls on January 15, 2027 at 08:00 UTC. Paste any timestamp above to get UTC, local and ISO 8601 dates, or turn a date back into a timestamp.

A Unix timestamp (also called Epoch time) is the number of seconds elapsed since January 1, 1970, 00:00:00 UTC. It is the universal standard for storing and transmitting time in software systems, used by every major operating system, database, and programming language. The current Unix time is shown live at the top of this tool, updating every second.

Because it is a simple integer, Unix time is easy to store, compare, and calculate. Subtracting two timestamps gives the exact duration between them. Adding 86,400 gives exactly one day later in UTC (a local calendar day can last 23 or 25 hours when daylight saving time changes). This simplicity is why it became the global standard despite numbers like 1768175999 looking abstract to human eyes.

Seconds vs. Milliseconds

Standard Unix timestamps count in seconds and are 10 digits long (e.g. 1768175999). JavaScript and many modern APIs use milliseconds instead, producing 13-digit numbers (e.g. 1768175999000). This converter detects automatically based on digit count.

For developers: use this tool to verify API responses, debug time-based bugs, and convert log timestamps into readable dates. Combine with our Timezone Converter and World Clock for full time zone coverage.

Seconds, Milliseconds or Something Else?

The converter picks the unit from the size of the number. You can override it with the Input Unit menu.

UnitDigits todayExample (same moment)Typical source
Seconds101800000000Unix date +%s, PHP time(), most APIs and JWT exp claims
Milliseconds131800000000000JavaScript Date.now(), Java System.currentTimeMillis()
Microseconds161800000000000000PostgreSQL internals, Python time.time_ns() // 1000
Nanoseconds191800000000000000000Go UnixNano(), time.time_ns()

Auto-detect rules: below 100 billion is read as seconds (that covers every date up to the year 5138), up to 14 digits as milliseconds, 15 to 17 digits as microseconds and 18 or more as nanoseconds. Very large nanosecond values lose a little precision in the browser, but never enough to change the millisecond.

Timestamp Milestones

Timestamp (seconds)UTC date and timeWhy it matters
0Jan 1, 1970 00:00:00The Unix epoch
1,000,000,000Sep 9, 2001 01:46:40First 10-digit timestamp
1,234,567,890Feb 13, 2009 23:31:30The "1234567890" moment
1,700,000,000Nov 14, 2023 22:13:20Recent round number
1,800,000,000Jan 15, 2027 08:00:00Next round number
2,000,000,000May 18, 2033 03:33:202 billion seconds
2,147,483,647Jan 19, 2038 03:14:07Last second a signed 32-bit counter can hold
4,294,967,295Feb 7, 2106 06:28:15Limit of an unsigned 32-bit counter
10,000,000,000Nov 20, 2286 17:46:40Timestamps grow to 11 digits

The Year 2038 Problem in Practice

A signed 32-bit integer tops out at 2,147,483,647. One second later, at 03:14:08 UTC on January 19, 2038, it wraps to −2,147,483,648, which software reads as 20:45:52 UTC on December 13, 1901. Linux and the major operating systems have used a 64-bit time_t on 64-bit hardware for years, and 64-bit counters last for billions of years. The risk sits in places nobody looks at often:

  • MySQL TIMESTAMP columns, which stop at 2038-01-19 03:14:07 UTC. DATETIME or a BIGINT avoids it.
  • File formats and network protocols with a fixed 32-bit time field.
  • Embedded devices, older 32-bit builds and firmware that will still be running in 2038.
  • Any code that already handles future dates, such as 30-year loan schedules or certificates, which can fail well before 2038.

Test by feeding 2147483648 (one past the limit) into the system and checking that it reads as 2038, not 1901.

Get the Current Timestamp in Code

Language or toolSecondsTimestamp to date (UTC)
JavaScriptMath.floor(Date.now() / 1000)new Date(ts * 1000).toISOString()
Python 3int(time.time())datetime.fromtimestamp(ts, tz=timezone.utc)
PHPtime()gmdate('c', $ts)
Java 8+Instant.now().getEpochSecond()Instant.ofEpochSecond(ts)
Gotime.Now().Unix()time.Unix(ts, 0).UTC()
C#DateTimeOffset.UtcNow.ToUnixTimeSeconds()DateTimeOffset.FromUnixTimeSeconds(ts)
Bash (GNU)date +%sdate -u -d @1800000000
PostgreSQLextract(epoch from now())to_timestamp(ts)
MySQLUNIX_TIMESTAMP()FROM_UNIXTIME(ts) (session time zone)

Common mistakes

  • Mixing units. Passing seconds to new Date() in JavaScript gives a date in January 1970. Multiply by 1,000 first.
  • Treating local time as UTC. A timestamp has no time zone. The zone only appears when you format it, so always say which one you used.
  • Adding 86,400 for "tomorrow" in local time. On daylight saving change days a local day lasts 23 or 25 hours. Add calendar days in a date library instead.

To convert the resulting time between cities, use the time zone converter; for the gap between two dates, the days between dates calculator.

Method and sources. Unix time as defined in POSIX (IEEE Std 1003.1, "Seconds Since the Epoch"): 86,400 seconds per day, leap seconds not counted. All dates in the tables were computed with the same JavaScript Date conversion this page uses. 32-bit limits: 231 − 1 = 2,147,483,647 and 232 − 1 = 4,294,967,295. MySQL TIMESTAMP range from the MySQL 8.0 reference manual. Leap second decision: Resolution 4 of the 27th General Conference on Weights and Measures (2022). Conversions run in your browser; nothing you enter is sent anywhere.

Unix Timestamp Questions

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 seconds, milliseconds, microseconds and nanoseconds from the size of the number.

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.fromtimestamp(1748000000, tz=datetime.timezone.utc) for a timezone-aware UTC datetime. Avoid utcfromtimestamp(), which returns a naive datetime and has been deprecated since Python 3.12. 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. In 2022 the General Conference on Weights and Measures decided to stop adding leap seconds by 2035; none has been added since the end of 2016.

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.

Count the digits. A current timestamp in seconds has 10 digits (like 1800000000) and in milliseconds 13 digits (1800000000000). If a date converts to January 1970, you probably treated milliseconds as seconds in reverse, or passed seconds to a function that expects milliseconds. If it lands tens of thousands of years in the future, you read milliseconds as seconds.

Yes. A timestamp counts seconds from a fixed instant in UTC, so 1800000000 is the same moment in New York, London and Tokyo. Only the way it is displayed changes: it is 3:00 AM EST on January 15, 2027 in New York and 5:00 PM the same day in Tokyo.

Systems that store time in a signed 32-bit integer overflow after 03:14:07 UTC on January 19, 2038 and jump back to December 13, 1901. Systems using 64-bit time are not affected. Check older databases (MySQL TIMESTAMP columns), embedded devices and binary file formats.