How to use this tool
- Type a timestamp in the timestamp field, or pick a date in the date field. Don't worry about precision — the tool auto-detects whether you've entered seconds, milliseconds, microseconds, or nanoseconds based on digit count.
- See every format simultaneously — UTC, your local time, ISO 8601, RFC 2822, relative ("3 hours ago"), and the underlying integer in both seconds and milliseconds.
- Copy what you need with the per-row Copy button. To share the exact scenario with someone else, use the "Copy shareable link" button at the bottom.
What is a Unix timestamp?
A Unix timestamp is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC — the "Unix epoch." It's the standard way computers represent a moment in time as a single integer, used in databases, log files, JWT tokens, API responses, file metadata, and virtually every programming language. Because it's just an integer counted from a fixed reference, it sidesteps the messiness of time zones, daylight saving rules, and locale-specific date formats: a timestamp is always the same exact moment in absolute time, regardless of where you're standing on the planet.
The convention emerged from Bell Labs in the early 1970s when Unix's designers needed a compact way to store time. They picked the start of 1970 as a round, near-recent date, and the choice stuck. Today, Unix timestamps appear in cookie expiration headers, JWT tokens (the iat, exp, and nbf claims), database created_at columns, file modification times, blockchain block timestamps, and cron schedules.
The trade-off is human readability. The integer 1735689600 is unambiguous to a computer but means nothing to a human until you convert it to "January 1, 2025, 00:00:00 UTC." That's what this tool does, in both directions.
Seconds, milliseconds, microseconds, nanoseconds
Different systems use different precisions. Most Unix tools, Python, PHP, and database columns store timestamps in seconds (10 digits for current dates). JavaScript, Java, and many web APIs use milliseconds (13 digits). Some monitoring and logging tools use microseconds; Go's time package and high-precision logs use nanoseconds.
| Precision | Digits today | Example | Common uses |
|---|---|---|---|
| Seconds | 10 | 1735689600 | Unix, Python, PHP, MySQL, PostgreSQL |
| Milliseconds | 13 | 1735689600000 | JavaScript, Java, MongoDB, many REST APIs |
| Microseconds | 16 | 1735689600000000 | Some observability tools, Python time.time_ns() divided by 1000 |
| Nanoseconds | 19 | 1735689600000000000 | Go, eBPF tracing, financial market data |
This converter auto-detects which one you've entered based on digit count and converts accordingly. If you paste 1735689600000, it knows to treat it as milliseconds rather than as a seconds-based timestamp far in the future.
Common timestamp values
| Reference point | Timestamp (seconds) |
|---|---|
| Unix epoch (Jan 1, 1970 00:00 UTC) | 0 |
| 1 hour | 3,600 |
| 1 day | 86,400 |
| 1 week | 604,800 |
| 1 month (30.44 days average) | 2,629,743 |
| 1 year (365.25 days) | 31,557,600 |
| Y2038 boundary (32-bit signed limit) | 2,147,483,647 |
Time zones — the most common source of bugs
Unix timestamps are timezone-agnostic by design — the integer 1735689600 represents the same exact moment everywhere on Earth. The confusion creeps in when you convert it to a human-readable date, because the display depends on which time zone you choose.
The classic bug: a developer in Tokyo (UTC+9) sees 2025-01-01 09:00:00 for timestamp 1735689600 in their console. A teammate in Los Angeles (UTC-8) sees 2024-12-31 16:00:00 for the same timestamp. They both think the system has a bug, when actually both are correct displays of the same underlying moment.
This tool always shows you UTC and your browser's local time at once, plus an arbitrary zone you can pick from the selector above. If you're debugging a server in a different region than yours, set the selector to that server's zone to read the timestamps as the server would.
Rule of thumb: store and transmit timestamps in UTC (or as Unix integers, which are inherently UTC). Convert to local time only at the very last moment, in the UI. This avoids the off-by-N-hours bugs that haunt date-handling code.
The Year 2038 problem
On January 19, 2038, at 03:14:07 UTC, Unix timestamps stored as signed 32-bit integers will overflow. The maximum representable timestamp is 2,147,483,647 — and the very next second can't fit, wrapping the value to a negative number that some systems will interpret as December 13, 1901. This is sometimes called Y2038, the Epochalypse, or Y2K38.
Most modern systems already store timestamps as 64-bit integers, which extends the range to roughly 292 billion years — enough that the universe will end first. But legacy code, embedded firmware, old database schemas with INT (not BIGINT) timestamp columns, and protocols with fixed 32-bit time fields can still trip on this.
If you maintain old C code, embedded systems, or database tables holding timestamps as 32-bit values, audit them now. The fix is usually trivial — widen the column or struct field to 64 bits — but the deadline is approaching at exactly one second per second.
Excel and the 1900 epoch
Excel doesn't use Unix's 1970 epoch — it uses January 1, 1900, and stores dates as a serial number equal to the number of days since that origin. So 1 is January 1, 1900; 45,658 is January 1, 2025. Times within a day are fractional — 45658.5 is noon on January 1, 2025.
To convert between the two systems, the magic number is 25,569 — the number of days between Jan 1, 1900 and Jan 1, 1970. Excel formulas: Unix seconds → Excel serial date is =A1/86400+25569; Excel serial date → Unix seconds is =(A1-25569)*86400.
Caveats: Excel's leap-year handling has a historical bug — it incorrectly treats 1900 as a leap year for compatibility with 1980s Lotus 1-2-3 spreadsheets, so dates before March 1, 1900 are off by one day. And Excel for Mac historically used a 1904 epoch — verify which one your file uses with =DATE(1900,1,1) (returns either 1 on Windows or 1462 on a Mac 1904 file). The Excel helper above does the conversion for you in either direction; for Mac 1904 files, replace 25569 with 24107 in the formulas.
Programming language reference
Quick reference for "current Unix timestamp" and "Unix timestamp to readable date" in 14 common languages and tools:
| Language | Current timestamp | Timestamp → date |
|---|---|---|
| Python | int(time.time()) | datetime.fromtimestamp(ts, tz=timezone.utc) |
| JavaScript | Math.floor(Date.now() / 1000) | new Date(ts * 1000).toISOString() |
| Java | Instant.now().getEpochSecond() | Instant.ofEpochSecond(ts) |
| Go | time.Now().Unix() | time.Unix(ts, 0).UTC() |
| Ruby | Time.now.to_i | Time.at(ts).utc |
| PHP | time() | date('c', $ts) |
| C# | DateTimeOffset.UtcNow.ToUnixTimeSeconds() | DateTimeOffset.FromUnixTimeSeconds(ts) |
| C++ (C++20) | std::chrono::system_clock::now() | std::chrono::sys_seconds{seconds{ts}} |
| Rust (chrono) | Utc::now().timestamp() | DateTime::from_timestamp(ts, 0) |
| PostgreSQL | EXTRACT(EPOCH FROM NOW()) | TO_TIMESTAMP(ts) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(ts) |
| SQLite | unixepoch() | datetime(ts, 'unixepoch') |
| Bash | date +%s | date -ud @ts |
| PowerShell | [DateTimeOffset]::UtcNow.ToUnixTimeSeconds() | [DateTimeOffset]::FromUnixTimeSeconds(ts) |
Tips and keyboard shortcuts
A few productivity touches worth knowing:
- Press
?anywhere on the page (when no input is focused) to see all keyboard shortcuts. - Press
/to jump straight to the timestamp input from anywhere on the page. - Press
Escwhile focused on an input to clear it. - The shareable link at the top of the main converter encodes both the timestamp and the selected zone, so you can paste it into Slack, GitHub, or a forum and the recipient sees your exact scenario.
- For batch conversion, paste log lines or CSV columns directly — the tool extracts every 10–13 digit number it finds, which catches Unix timestamps in seconds and milliseconds at any current-era date.
Related tools
Two sibling tools cover specific use cases that deserve their own pages: