Developer · Time
Unix Timestamp (Epoch) Converter
Paste a Unix epoch, seconds, milliseconds, microseconds, or nanoseconds, and read it back as a date in UTC, Sri Lanka time, and your own zone, plus relative time, ISO-week facts, and a Year-2038 check. Or go the other way, date to epoch. Everything runs in your browser; nothing is uploaded.
By Induwara AshinsanaUpdated Jun 8, 2026
How it works
A Unix timestamp is a single integer: the number of seconds since the epoch, 1970-01-01T00:00:00Z, defined by POSIX.1-2017 §4.16. Because it carries no time zone, the same number means the same instant everywhere, the converter's only job is to render that instant clearly and to reverse the process exactly.
- Resolve the unit. On Auto-detect, the digit count decides the unit. The canonical lengths (10 = seconds, 13 = milliseconds, 16 = microseconds, 19 = nanoseconds) each sit inside a band:
- 1–11 digits → seconds
- 12–14 digits → milliseconds
- 15–17 digits → microseconds
- 18–19 digits → nanoseconds
- Normalise to milliseconds. The value is scaled to milliseconds using exact BigInt arithmetic so a 19-digit nanosecond figure never loses precision to floating point. Microsecond and nanosecond inputs are floor-divided; any sub-millisecond remainder is reported separately rather than rounded into the date.
- Build the civil date. The millisecond instant is decomposed into a year/month/day and hour/minute/second using UTC fields only, so the host machine's local offset can never leak into a UTC answer. This matches the POSIX relation
days = ⌊seconds / 86400⌋with the remainder giving the time of day, cross-checked against Howard Hinnant's constant-time days-to-civil algorithm. - Apply target offsets. UTC is shown with the Z suffix; Sri Lanka adds a fixed +05:30 (Asia/Colombo, no DST since 1996); your local zone uses the offset your browser reports for that exact instant, so historical daylight saving is handled correctly.
- Format. Each zone is emitted as ISO 8601 / RFC 3339, with an RFC 2822 string for email and HTTP-style dates. The same epoch is echoed in all four units for easy copy-paste.
- Reverse direction. Date → Epoch parses your calendar input in the chosen zone, converts it to a UTC instant, and reads back the epoch in every unit. The forward and reverse paths are inverses, so a value round-trips to itself.
- Derived facts. Day of week comes from the UTC weekday; day of year by differencing from 1 January; the ISO-8601 week number uses the Monday-start, first-Thursday rule; and leap years follow the Gregorian rule
(y%4==0 && y%100!=0) || y%400==0.
Worked examples
Frequently asked questions
A Unix timestamp (or epoch time) is the number of seconds that have elapsed since 1970-01-01T00:00:00Z (1970-01-01T00:00:00Z), ignoring leap seconds. It is a single integer that names an exact instant in time, independent of any time zone, which is why databases, logs, and APIs store dates this way.
Paste the number into the converter above. It works out whether you gave it seconds, milliseconds, microseconds, or nanoseconds, then shows the matching calendar date in UTC, Sri Lanka time, and your own local zone at once. You can also switch to the Date → Epoch tab to go the other way.
The original POSIX definition is in seconds, so a current timestamp is 10 digits (for example 1700000000). JavaScript, Java, and many log formats use milliseconds, which is 13 digits. This tool auto-detects by digit count, 1–11 digits reads as seconds, 12–14 as milliseconds, 15–17 as microseconds, 18–19 as nanoseconds, and you can override the unit if a value is ambiguous.
The live ticker at the top of the tool shows the current Unix time in both seconds and milliseconds, updating every second. Click "Use now" to drop the current millisecond value straight into the converter.
Systems that store Unix time in a signed 32-bit integer can only count up to 2,147,483,647 seconds, which is reached at 2038-01-19T03:14:07Z. One second later the value overflows to a negative number and the clock appears to jump back to December 1901. This tool flags any timestamp past that boundary so you can spot 32-bit overflow bugs.
Yes. A negative epoch counts seconds before 1970-01-01. For example -1 is 1969-12-31T23:59:59Z. Auto-detect is tuned for modern positive values, so for clearly pre-1970 inputs pick the unit explicitly to be safe.
Asia/Colombo has been a constant +05:30 with no daylight saving since 1996-10-26, per the IANA Time Zone Database. Sri Lanka briefly used +05:30 / +06:00 / +06:30 in the mid-1990s, but for any timestamp from 1996 onward a flat +05:30 is exact, so the tool adds five hours thirty minutes to UTC.
No, and that is correct. POSIX time deliberately ignores leap seconds: every day is treated as exactly 86,400 seconds. This tool matches the standard, which is what databases and programming languages also do, so your converted values line up with the rest of your stack.
Sources & references
- IEEE Std 1003.1-2017 (POSIX.1) §4.16: Seconds Since the Epoch
- ISO 8601-1:2019: Date and time representations
- RFC 3339: Date and Time on the Internet: Timestamps
- RFC 2822 §3.3: Date and Time Specification
- IANA Time Zone Database: Asia/Colombo (+05:30)
Conversion logic was last cross-checked against these standards on 2026-06-08. Unix time ignores leap seconds by design (POSIX §4.16), so every day is treated as exactly 86,400 seconds.
Related tools
Comments & feedback
Spotted a bug or want an improvement? Tell us, our team reviews every comment, and good ideas get built. Comments are public and anonymous.
Found a bug, edge case, or want to suggest an improvement?
Email me at [email protected] , most fixes ship within 24 hours.