Unix Timestamp Converter

Convert any Unix timestamp to a human-readable date and time.

Our converter:

• auto-detects seconds (10 digits) and milliseconds (13 digits)
• shows UTC and local time
• displays multiple formats including ISO 8601 and RFC 2822

Convert any date and time to its Unix timestamp.

Select a date, choose your timezone, and get the epoch time in both seconds and milliseconds.

Perfect for:

• API development
• database queries
• debugging time-related issues

Unix time is a system for tracking a point in time as the number of seconds elapsed since the Unix epoch, defined as 00:00:00 UTC on January 1, 1970. The IEEE and The Open Group codify this in the POSIX standard (IEEE Std 1003.1), where it is formally called "Seconds Since the Epoch."

A key subtlety documented by POSIX is that Unix time deliberately ignores leap seconds, so each day is treated as exactly 86,400 seconds. Because the value is a single integer independent of time zones, it is unambiguous across systems.

Storing time as an integer, as MDN Web Docs notes for JavaScript's Date object, makes arithmetic and comparison trivial compared with parsing formatted date strings.

A 10-digit Unix timestamp counts seconds since the epoch, while a 13-digit timestamp counts milliseconds, and mixing them is the most common conversion error.

Per MDN Web Docs, JavaScript's Date.now() and getTime() return milliseconds, so 1700000000000 is a valid JS value. By contrast, POSIX C functions like time() and Python's time.time() truncation, plus most SQL databases and the Bash date +%s command, operate in seconds (1700000000).

To convert between them, multiply seconds by 1,000 or divide milliseconds by 1,000.

Our converter auto-detects the unit by digit count, but when writing code you should always confirm which unit your language or API expects to avoid dates that land in 1970 or thousands of years in the future.

You can generate the current Unix timestamp with a single call in almost every programming language.

• In JavaScript, MDN Web Docs recommends Math.floor(Date.now() / 1000) for seconds or Date.now() for milliseconds.
• In Python, time.time() returns a float of seconds since the epoch, matching the C library time() function defined by POSIX.
• On the command line, GNU coreutils' date +%s prints the current second-precision timestamp, while PHP uses time() and Go uses time.Now().Unix().
• SQL engines expose functions such as UNIX_TIMESTAMP() in MySQL and EXTRACT(EPOCH FROM now()) in PostgreSQL.

All of these reference the same 1970 UTC origin, so values are directly interchangeable once you normalize the seconds-versus-milliseconds unit.

Use a Unix timestamp for storage and arithmetic, and ISO 8601 for human-readable exchange and logs.

ISO 8601 is the international standard for representing dates and times as strings like 2023-11-14T22:13:20Z, where the uppercase T separates the date from the time and the trailing Z denotes UTC (Zulu time). Those letters are case-sensitive, so if you are tidying up strings copied from mixed-case sources a quick pass through a case converter keeps them parseable. The IETF's RFC 3339 profiles ISO 8601 for use on the Internet and is what most JSON APIs adopt for date fields, since JSON itself (RFC 8259) has no native date type.

A Unix integer is more compact and locale-neutral but not self-describing, whereas an ISO 8601 string is instantly legible. Many systems store the integer internally and serialize to ISO 8601 at the API boundary to get the benefits of both.

A Unix timestamp has no time zone because it always references a single instant measured from the epoch in UTC. Time zones only matter when you render that instant as a wall-clock date for a user.

The IANA Time Zone Database (the tz database) is the authoritative source that operating systems and languages use to map an instant to local time, including historical daylight-saving rules.

The best practice, echoed by MDN Web Docs and countless engineering guides, is to store and transmit timestamps in UTC and convert to the viewer's local zone only at display time. This eliminates ambiguity around daylight-saving transitions and makes cross-region comparisons reliable and reproducible.

The Year 2038 problem is the point at which 32-bit signed integers storing Unix time will overflow, occurring at 03:14:07 UTC on January 19, 2038.

A signed 32-bit value maxes out at 2,147,483,647 seconds; one second later it wraps to a large negative number, which naive code interprets as December 1901. This mirrors the historical concern around the Year 2000 problem but is rooted in the fixed width of the C time_t type on legacy platforms.

Modern operating systems and languages have largely migrated to 64-bit time_t, which pushes overflow roughly 292 billion years into the future. Embedded systems and old file formats remain the main risk areas developers should audit.

Unix timestamps are the backbone of time handling in backend systems, logs, and APIs because they sort, diff, and compare as plain integers.

Databases store created_at and updated_at columns as epoch values or timestamp types derived from them, and cache layers use expiry timestamps to invalidate entries. Security tokens rely on them too: the JWT standard, RFC 7519, defines the exp (expiration) and iat (issued-at) claims as NumericDate values, which are literally seconds since the Unix epoch.

Distributed logs and event streams use timestamps to establish ordering, and rate limiters compare the current epoch against stored windows. Their language-agnostic nature makes them ideal for passing time across service boundaries.

Negative Unix timestamps represent instants before the epoch, so -86400 corresponds to December 31, 1969 at 00:00:00 UTC. The POSIX definition allows the seconds count to be negative, and languages such as JavaScript honor this: MDN Web Docs documents that the Date object accepts negative millisecond values to express pre-1970 dates.

This is useful for historical data, birthdates, or archival records.

Beware, however, that some older systems, databases, and 32-bit tools treat Unix time as unsigned or reject negative input, silently clamping the value to the epoch or throwing an error. When handling historical dates, verify that every layer of your stack, from the database column type to the client library, supports signed timestamps.

• The most frequent mistake is confusing seconds with milliseconds, which produces dates decades off or stuck in 1970. Always confirm the unit your source uses before converting, since JavaScript emits milliseconds while most backends emit seconds.
• A second pitfall is assuming a timestamp carries a time zone; it does not, so applying a local offset twice yields wrong wall-clock times.
• Others include ignoring the Year 2038 limit on 32-bit fields, and expecting Unix time to account for leap seconds, which POSIX explicitly excludes.
• Finally, avoid parsing formatted date strings by hand; use standard libraries and prefer ISO 8601 (RFC 3339) for interchange, as MDN Web Docs advises, to sidestep ambiguous formats like MM/DD versus DD/MM.