Unix Timestamp and Epoch Time Explained
Unix timestamps count elapsed seconds from 1970-01-01T00:00:00Z in the usual POSIX convention. An epoch converter turns this numeric representation into a date. JavaScript Date APIs commonly use milliseconds instead of seconds.
Convert Unix Timestamp to Date
Enter the timestamp and choose its unit explicitly. Inspect UTC and local output before copying a date into a log or support message. A valid number in the wrong unit can produce a plausible but completely wrong date.
Convert Date and Time to Unix Timestamp
Enter a date and time with a clear zone convention. Local times can be ambiguous during daylight-saving transitions. Confirm whether the destination expects seconds or milliseconds and avoid stripping that context from exported values.
Seconds vs Milliseconds
Milliseconds are one thousandth of a second. Contemporary seconds and milliseconds often differ in digit length, but length alone is not a universal rule for historical or future dates. Prefer the source API’s documented unit.
UTC, Local Time and Time Zones
The timestamp denotes an instant; a timezone determines how it is displayed. UTC is useful for comparing logs from different regions. Local output uses the browser’s timezone, so another user may see a different clock time for the same instant.
More examples and technical details
What Is a Unix Timestamp?
A Unix timestamp is the number of seconds that have elapsed since 1 January 1970 at 00:00:00 UTC, a moment known as the Unix epoch. It is a single integer, which makes it trivially easy to store, compare, sort, and subtract. Two timestamps subtracted give you a duration in seconds with no calendar arithmetic involved.
One detail catches people out: Unix time does not count leap seconds. When a leap second is inserted, the count effectively repeats or stretches a value rather than advancing past it. This keeps the arithmetic simple (every day is exactly 86,400 seconds) at the cost of not being a true count of elapsed physical seconds.
Seconds vs Milliseconds: the Most Common Date Bug
Different platforms count in different units, and mixing them is one of the most frequent date bugs in production code. The quickest way to tell them apart is digit count: a 10-digit value is seconds, a 13-digit value is milliseconds.
JavaScript is the usual source of the confusion. Date.now() and the Date constructor both work in milliseconds, while most Unix system calls, many database column types, JWT claims such as exp and iat, and a large share of REST APIs use seconds. When you cross that boundary, divide by 1000 and floor, or multiply by 1000, and label the variable with its unit so the next reader does not have to guess.
Reference Timestamps Worth Recognising
Memorising a few landmark values makes it easy to eyeball whether a timestamp in a log file is plausible before you convert it.
| Timestamp | UTC date | Significance |
|---|---|---|
| 0 | 1 January 1970 | The Unix epoch, the zero point of the whole scheme |
| 1000000000 | 9 September 2001 | The first billion-second mark, widely celebrated at the time |
| 1500000000 | 14 July 2017 | A convenient round modern reference point |
| 1700000000 | 14 November 2023 | Useful for sanity checking recent data |
| 2000000000 | 18 May 2033 | The two billion mark, still comfortably in the future |
| 2147483647 | 19 January 2038 | The maximum value of a signed 32-bit integer |
The Year 2038 Problem
Older systems store time in a signed 32-bit integer called time_t. The largest value such an integer can hold is 2,147,483,647, which corresponds to 03:14:07 UTC on 19 January 2038. One second later the value overflows and wraps to the most negative integer, interpreted as 13 December 1901. Any code that compares, sorts, or schedules on that value will behave unpredictably.
The fix is straightforward in principle: store time in a signed 64-bit integer, which pushes the limit roughly 292 billion years out. Modern operating systems and language runtimes have largely made that move. The remaining risk sits in embedded devices, old binary file formats, database columns declared as 32-bit integers, and network protocols that pinned the field width. It is worth checking any long-lived schema now rather than in 2037.
Time Zones, and Why Timestamps Avoid a Whole Class of Bugs
A Unix timestamp is always UTC. It carries no time zone, no offset, and no daylight saving information. The zone is applied only when you render the value for a human. That property is exactly why storing timestamps beats storing local date strings: the stored value has one unambiguous meaning, and two servers in different regions will always agree on what it represents.
Store a local string such as "2024-03-10 02:30" instead and you inherit every ambiguity of the calendar. That particular moment does not exist in parts of the United States because clocks jump forward, and an hour in autumn occurs twice. Timestamps have no such gaps or repeats.
ISO 8601
When you do need a human readable form, ISO 8601 is the format to reach for. It writes the date largest unit first, so string sorting matches chronological sorting, and it makes the offset explicit.
Working with dates in code often means working with encodings too. Browse the full developer tools collection for JSON formatting, number base conversion, and encoding utilities that sit alongside date handling.
Frequently asked questions
How do I convert a Unix timestamp to a date?
Enter it, select seconds or milliseconds and read the UTC or local result.
Are Unix time and epoch time the same?
Unix time uses the Unix epoch. Other systems can use different epochs, so check the source convention.
Is my timestamp in seconds or milliseconds?
Check the source API. Milliseconds are 1000 times the corresponding seconds value.
Does Unix time include a time zone?
The numeric instant has no display timezone; conversion to a calendar date uses a chosen zone.
What is the current Unix timestamp?
The live clock on the tool shows the current value from your device’s clock.