--- title: "Unix Time Explained — Epoch Seconds, Milliseconds and the Year 2038 Problem | WatchTime Online" url: https://watchtimeonline.com/guides/unix-time-explained.html description: "What a Unix timestamp is, why it starts in 1970, how to tell seconds from milliseconds, why Unix time ignores leap seconds, and what happens in 2038." --- [Home](https://watchtimeonline.com/) › [Guides](https://watchtimeonline.com/guides/index.html) # Unix time, explained Computers mostly don't store dates as dates. They store a single number that counts seconds from a fixed moment in 1970. Here's how that number works and where it catches people out. By [Milton S.](https://watchtimeonline.com/about.html) Published 31 October 2026 A Unix timestamp is the number of seconds that have elapsed since **00:00:00 UTC on 1 January 1970**, a moment known as the Unix epoch. The start of 31 October 2026 in UTC, for example, is 1793404800. Every computer, wherever it is, agrees on that number for that instant, which is exactly why it's so useful. ## Why a single number? A date written as "31/10/2026 9:00" needs a time zone, a calendar and a date format to be understood, and each of those can be ambiguous. A timestamp needs none of them. It identifies one instant, the same everywhere. Comparing two times is simple subtraction, sorting is trivial, and storing it takes a few bytes. Time zones only come in at the very end, when the number is converted into a local date for a person to read. That's also the cleanest way to think about it: a timestamp is the *instant*; the time zone is just the *presentation*. The same timestamp shows as 05:00 in New York and 10:00 in London during winter, and both are correct. ## Why 1970? There's nothing astronomical about it. The Unix operating system was developed at Bell Labs around 1969–1971, and its designers needed a recent, round starting point. After some early versions used other epochs, 1 January 1970 stuck and became the convention almost everywhere, from databases to phone operating systems to web browsers. Dates before 1970 are simply negative numbers. Midnight UTC on 1 January 1969 is −31536000. ## Seconds or milliseconds? The classic Unix timestamp counts seconds. JavaScript, Java and many web APIs count **milliseconds** instead, which makes the number a thousand times bigger. The easy tell is length: for any date between 2001 and 2286, a seconds timestamp has 10 digits and a milliseconds timestamp has 13. Mixing them up is one of the most common date bugs. Treat a milliseconds value as seconds and you get a date tens of thousands of years in the future; treat seconds as milliseconds and you land a few weeks after 1 January 1970. If a converted date comes out as January 1970, that's almost always the cause. The [Unix timestamp converter](https://watchtimeonline.com/tools/unix-timestamp-converter.html) detects which unit you've pasted automatically. Some systems go further, to microseconds (16 digits) or nanoseconds (19 digits), mostly for logs and high-precision measurement. ## Unix time and leap seconds Since 1972, 27 leap seconds have been added to UTC to keep it in step with the Earth's slightly irregular rotation, most recently at the end of 2016. Unix time ignores them. It pretends every day has exactly 86,400 seconds, so on the rare occasions a leap second is inserted, the Unix clock either repeats a second or is gently smeared across a longer period, depending on the system. For almost everyone this doesn't matter, and it has a big advantage: any day's start can be calculated by multiplying the number of days since 1970 by 86,400. In 2022, the international body responsible for the definition of UTC voted to stop adding leap seconds by 2035, which will remove the issue going forward. The [leap year guide](https://watchtimeonline.com/guides/leap-years.html) explains how leap seconds differ from leap days. ## The year 2038 problem Many older systems stored Unix time as a signed 32-bit integer, which can't go higher than 2,147,483,647. That value corresponds to **03:14:07 UTC on 19 January 2038**. One second later, a 32-bit counter overflows to a large negative number, and software reading it will think the date is in December 1901. Modern operating systems, languages and databases have moved to 64-bit time values, which won't overflow for billions of years, so most everyday software is already safe. The risk is in older embedded devices, file formats and databases with 32-bit fields, which is why it's still a known item on engineering checklists. ## Reading and writing timestamps - **Store and transmit in UTC** (or as timestamps), and convert to local time only for display. - **When you need a human-readable form in data, use ISO 8601** with an offset, such as `2026-10-31T09:00:00-04:00` or `2026-10-31T13:00:00Z`. It sorts correctly as text and leaves no doubt about the zone. - **Don't store a local time without its zone.** "2026-11-01 01:30" in New York happened twice that night, once before and once after the clocks went back. The [daylight saving guide](https://watchtimeonline.com/guides/daylight-saving-time.html) explains the repeated hour. ## Related tools Convert timestamps in either direction with the [Unix timestamp converter](https://watchtimeonline.com/tools/unix-timestamp-converter.html), or convert a local time between zones with the [time zone converter](https://watchtimeonline.com/tools/time-zone-converter.html). ## Frequently asked questions ### What is the Unix epoch? 00:00:00 UTC on 1 January 1970. A Unix timestamp counts the seconds since that moment. ### How do I tell if a timestamp is in seconds or milliseconds? Count the digits. For present-day dates, 10 digits means seconds and 13 digits means milliseconds. ### Does a Unix timestamp depend on time zone? No. It identifies the same instant everywhere. Time zones only affect how that instant is displayed as a local date and time. ### What happens in 2038? Systems that store Unix time as a signed 32-bit number overflow after 03:14:07 UTC on 19 January 2038. Systems using 64-bit time, which includes most modern software, are unaffected. --- Source: https://watchtimeonline.com/guides/unix-time-explained.html