Unix Timestamp Converter
Convert Unix epoch timestamps to readable date and time strings across UTC and global timezones, or convert calendar dates into epoch timestamps with second, millisecond, and nanosecond precision. Conforms to POSIX IEEE Std 1003.1 and ISO 8601 standards.
How to use
Enter a Unix timestamp in seconds, milliseconds (13 digits), microseconds (16 digits), or nanoseconds (19 digits).
View the instant conversion across UTC, your local timezone, ISO 8601, and RFC 2822 formats.
Switch to the Date to Timestamp tab to select any date and time on the calendar and generate its epoch integer.
Inspect the World Clock panel to view corresponding local times in major international financial and developer hubs.
Use the Code Snippets tab to copy ready-to-use timestamp generation and parsing syntax in JavaScript, Python, Go, PHP, Java, and SQL.
What is a Unix epoch timestamp?
The Unix timestamp (also known as POSIX time or Epoch time) measures the elapsed time as a count of seconds since 00:00:00 UTC on January 1, 1970 (the Unix Epoch), not counting leap seconds. Standardized in IEEE Std 1003.1 (POSIX), Unix time is the fundamental temporal representation across operating system kernels, databases, network protocols, and distributed software architectures.
Timestamp precision scales
| Scale | Digits (Approx) | Multiplier | Standard Application |
|---|---|---|---|
| Seconds (s) | 10 digits | 1 | Standard POSIX systems, HTTP headers, OAuth exp / iat JWT claims, and DNS TTL records. |
| Milliseconds (ms) | 13 digits | 103 | JavaScript Date.now(), Java System.currentTimeMillis(), and browser DOM event timestamps. |
| Microseconds (μs) | 16 digits | 106 | PostgreSQL timestamp types, Python time.time_ns() // 1000, and distributed tracing spans (OpenTelemetry). |
| Nanoseconds (ns) | 19 digits | 109 | Go time.Now().UnixNano(), Rust SystemTime, and high-frequency trading matching engines. |
Leap seconds and the Year 2038 problem
POSIX time ignores leap seconds by treating every calendar day as having exactly 86,400 seconds. When a leap second is inserted by the International Earth Rotation and Reference Systems Service (IERS), systems typically perform leap second smearing or repeat the 86,400th second.
Legacy 32-bit signed integer implementations of Unix time overflow on January 19, 2038 at 03:14:07 UTC (reaching 2,147,483,647 seconds), causing values to wrap around to negative numbers representing December 13, 1901. Modern 64-bit systems extend safe timestamp representation to approximately 292 billion years into the future.
ISO 8601 and RFC 3339 date representations
Human-readable dates are standardized by ISO 8601 and its Internet profile RFC 3339. A canonical representation follows the structure YYYY-MM-DDTHH:mm:ss.sssZ, where T separates the calendar date from the time of day, and Z denotes the zero UTC offset (Zulu time). When local offsets are applied, the format appends ±HH:mm.
Zero server transmission guarantee
Application logs, forensic audit timestamps, database primary key timestamps, and security tokens are processed entirely inside your local web browser session using client-side JavaScript. No timestamp values or date queries are logged or transmitted across the internet.
Frequently asked questions
What happens to Unix time during a leap second?
POSIX standard Unix time does not count leap seconds; every day is treated as having exactly 86,400 seconds. Major cloud providers (such as Google and AWS) use leap second smearing to gradually adjust system clocks over a 24-hour period.
How can I tell whether a timestamp is in seconds or milliseconds?
Standard Unix timestamps in seconds are currently 10 digits long (e.g., 1773340800 in year 2026). Timestamps in milliseconds are 13 digits long (e.g., 1773340800000). Our tool automatically detects the precision scale based on digit length.
What is the Year 2038 problem (Y2038)?
On January 19, 2038 at 03:14:07 UTC, 32-bit signed integers exceed their maximum positive value (2,147,483,647) and wrap around to negative numbers. All modern 64-bit architectures eliminate this issue.
Why does my local date differ from the UTC date?
Unix timestamps are strictly timezone-agnostic and anchored to UTC (00:00:00 GMT). When displayed in local time, your operating system adds or subtracts your region's UTC timezone offset (e.g., UTC+05:30 or UTC-05:00).
Are my timestamps or date conversions saved on a server?
No. All date calculations and timezone offsets are evaluated locally in your browser using standard JavaScript ECMAScript Date and Intl APIs. No data is sent to external servers.