What a Unix timestamp is
A Unix timestamp (also called epoch time or POSIX time) is the number of seconds elapsed since January 1, 1970 at 00:00:00 UTC, a reference instant known as the epoch. A value of 0 is that exact moment; 1000000000 landed on September 9, 2001; negative values represent dates before 1970.
The big advantage of this format is that it pins down an instant with no ambiguity: it doesn't depend on time zone, language, or each country's date format. 1759672800 is the same moment in Madrid, Mexico City, and Tokyo — only the way each local clock displays it changes. That's why it's the go-to format for storing dates in databases, stamping log entries, and exchanging dates between systems.
One technical footnote: Unix time ignores leap seconds. Every day counts exactly 86,400 seconds, which keeps the conversion between timestamp and date simple arithmetic, at the cost of being unable to represent an instant like 23:59:60.
Seconds, milliseconds, microseconds, and nanoseconds
The "classic" timestamp is in seconds, but many languages and systems use finer units. The quickest way to tell which unit a value is in is to count its digits: for present-day dates, each step down adds three.
| Unit | Digits for a current date | Example | Who uses it |
|---|---|---|---|
| Seconds | 10 | 1759672800 | date +%s, PHP time(), Go Unix(), most APIs |
| Milliseconds | 13 | 1759672800000 | JavaScript Date.now(), Java currentTimeMillis() |
| Microseconds | 16 | 1759672800000000 | PostgreSQL internally, Python time.time_ns() // 1000 |
| Nanoseconds | 19 | 1759672800000000000 | Go UnixNano(), Python time.time_ns() |
The converter detects the unit automatically using that same rule (up to 11 digits is seconds, 12–14 milliseconds, 15–17 microseconds, 18 or more nanoseconds), which gets it right for any date between 1973 and the year 5138. If an edge case doesn't fit, you can set the unit by hand in the dropdown.
Mixing up seconds and milliseconds is probably the single most common timestamp bug: a millisecond value read as seconds lands about 55,000 years in the future, and a seconds value read as milliseconds ends up in January 1970.
Reference timestamps
| Timestamp | UTC date and time | Why it's notable |
|---|---|---|
0 | 1970-01-01 00:00:00 | The epoch |
-1 | 1969-12-31 23:59:59 | The second before the epoch |
1000000000 | 2001-09-09 01:46:40 | The first 10-digit timestamp |
1234567890 | 2009-02-13 23:31:30 | Celebrated at the time for its digit sequence |
1500000000 | 2017-07-14 02:40:00 | |
2000000000 | 2033-05-18 03:33:20 | The next round number |
2147483647 | 2038-01-19 03:14:07 | Maximum of a signed 32-bit integer |
-2147483648 | 1901-12-13 20:45:52 | Minimum of a signed 32-bit integer |
The Year 2038 problem
For decades, many systems stored timestamps in a signed 32-bit integer (C's time_t on 32-bit platforms). That type tops out at 2147483647, which is January 19, 2038 at 03:14:07 UTC. One second later the value overflows to -2147483648, which reads as December 13, 1901.
Modern operating systems and languages have moved to 64 bits, which covers hundreds of billions of years. The risk lies in what got left behind: embedded devices, file formats and protocols with 32-bit fields, and database columns like MySQL's TIMESTAMP type, whose range ends in exactly 2038. The converter shows a warning whenever the instant falls outside the 32-bit range.
Output formats
- ISO 8601 / RFC 3339, like
2025-10-05T14:00:00Z. This is the recommended format for exchanging dates as text: it sorts alphabetically in chronological order and always carries a zone (Zfor UTC or an offset like-03:00). - In the selected zone: the same instant expressed as local time in an IANA zone (
America/New_York,Europe/London), with the offset that applies on that date — daylight saving time included. - HTTP date (RFC 9110), like
Sun, 05 Oct 2025 14:00:00 GMT. This is the format used in theDate,Expires, andLast-Modifiedheaders. - Relative, like "3 days ago" or "in 2 hours," handy for seeing at a glance whether a value is recent.
Converting a date to a timestamp
The date field accepts the common forms of ISO 8601: date only (2025-10-05), date and time (2025-10-05T14:00, or with a space instead of the T), with seconds and milliseconds, and with an explicit zone (Z, +02:00, or +0200). When the date doesn't specify a zone, it's read as local time in the selected time zone: 2025-10-05T10:00 in America/New_York is the same instant as 2025-10-05T14:00Z. That rule sidesteps the most common pitfall when converting dates by hand — not knowing which zone the original time was written in.
The difference between an instant, a local time, and an offset — and the bugs daylight saving time causes — is covered in depth in Unix Timestamps and Time Zones: Handling Dates Without Bugs.
Getting and converting timestamps from the shell and in code
| Environment | Current timestamp (seconds) | Timestamp to date |
|---|---|---|
| Bash (GNU) | date +%s | date -d @1759672800 |
| macOS / BSD | date +%s | date -r 1759672800 |
| JavaScript | Math.floor(Date.now() / 1000) | new Date(1759672800 * 1000) |
| Python | int(time.time()) | datetime.fromtimestamp(1759672800, tz=timezone.utc) |
| PHP | time() | date('c', 1759672800) |
| Go | time.Now().Unix() | time.Unix(1759672800, 0) |
| Java | Instant.now().getEpochSecond() | Instant.ofEpochSecond(1759672800) |
| PostgreSQL | extract(epoch from now()) | to_timestamp(1759672800) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(1759672800) |
In JavaScript, keep in mind that Date works in milliseconds: multiplying by 1000 when building from seconds — and dividing on the way back — is where most of the stray "January 1970" dates in user interfaces come from.
Privacy
All conversion happens in your browser using JavaScript's Intl API, which ships with the IANA time zone database built in. No value is sent to a server; the timestamp is only kept in the URL so you can share the result.