Unix Timestamp
Unix Timestamp
Current Unix Timestamp
—
Planning an event?Countdown Timer
What a Unix timestamp is
A Unix timestamp is the number of seconds elapsed since midnight UTC on 1 January 1970, a moment called the Unix epoch. It is a single integer with no timezone, no calendar and no daylight saving in it, which is exactly why it is the standard way to store an instant in time: two systems anywhere in the world will agree on the number, and only disagree when they format it for a human.
The one thing it deliberately gets wrong is leap seconds. Unix time pretends every day has exactly 86,400 seconds, so on the rare days that carried a leap second the timestamp repeats a value rather than advancing. That keeps the arithmetic simple at the cost of a second of accuracy roughly every 18 months.
Worked examples
| Timestamp | UTC date |
|---|---|
| 0 | 1 January 1970The epoch itself. |
| 1000000000 | 9 September 2001Widely celebrated among engineers at the time. |
| 1234567890 | 13 February 2009The sequential-digit timestamp. |
| 2147483647 | 19 January 2038The last instant a signed 32-bit time_t can hold. |
| -86400 | 31 December 1969Negative values run backwards from the epoch. |
Worth knowing
- Count the digits to tell the unit. A 10-digit value is seconds; a 13-digit value is milliseconds. JavaScript
Date.now()returns milliseconds, almost every other language returns seconds, and mixing them silently puts you in 1970 or the year 54,000. - A signed 32-bit timestamp overflows at 2,147,483,647 seconds, which falls on 19 January 2038. Systems still using a 32-bit
time_twill wrap to 1901. This is the Year 2038 problem. - Negative timestamps are valid and represent dates before 1970. Not every library handles them.
- A timestamp is always UTC. If a value appears to be in local time, something has already converted it, and converting again is the most common date bug in existence.
Frequently asked questions
- Is my timestamp in seconds or milliseconds?
- Count the digits. Ten digits is seconds and thirteen is milliseconds, for any date in the current era. If a date comes out in 1970 you have passed seconds to something expecting milliseconds; if it comes out tens of thousands of years in the future you have done the reverse.
- What is the Year 2038 problem?
- Older systems store Unix time in a signed 32-bit integer, which can hold at most 2,147,483,647 seconds. That runs out on 19 January 2038, after which the value overflows to a large negative number and the date reads as 1901. Modern platforms use 64-bit time and are unaffected, but embedded and legacy systems remain exposed.
- Does Unix time account for leap seconds?
- No, by design. It assumes every day is exactly 86,400 seconds long, so a leap second is absorbed by repeating a timestamp value rather than adding a new one. This keeps date arithmetic trivial and means Unix time is not a true count of elapsed SI seconds since the epoch.
- What timezone is a Unix timestamp in?
- UTC, always. The number itself carries no timezone at all: it is an offset from a fixed instant. A timezone is applied only when the value is formatted for display, which is why the same timestamp correctly shows different wall-clock times to users in different places.