Unix Time and Epoch Timestamps

What a Unix timestamp is

A Unix timestamp, also called epoch time or POSIX time, is a count of seconds since a fixed starting point: midnight UTC on 1 January 1970. That instant is the Unix epoch. Every timestamp is that starting point plus a number of seconds, so a larger number always means a later moment.

Two properties follow from the definition. The count is in UTC, so a timestamp has no time zone attached to it: 1,700,000,000 denotes one specific instant, and reading it in London, Lagos or Auckland is purely a display step. The other property is that leap seconds are not counted: every day in Unix time is exactly 86,400 seconds long.

Since one day is 86,400 seconds, timestamps are easy to reason about arithmetically: adding 86,400 moves you to the same UTC time on the next day, and adding 604,800 moves you a week.

Why the unit matters more than the number

Unix time itself is defined in seconds, but the value you meet in practice is often not in seconds. JavaScript's Date and a great many web APIs count milliseconds, so the current time in milliseconds is a 13-digit number such as 1700000000000, the same instant as the 10-digit 1700000000 above. Command-line tools such as date +%s, and many databases, use seconds.

The digit count is the quickest check. For dates around the present day, 10 digits means seconds and 13 digits means milliseconds. Microseconds and nanoseconds are also in circulation, at 16 and 19 digits, so a value that is 1,000 or 1,000,000 times too large is almost always a unit mismatch rather than a wrong date. The Unix timestamp converter works in seconds or milliseconds, and suggests switching when a value entered as seconds is large enough to be milliseconds.

Timestamps before 1970

The count runs in both directions. A date before the epoch produces a negative number, so -1 is 23:59:59 UTC on 31 December 1969 and -86,400 is the start of that day. Some languages, file formats and databases restrict timestamps to unsigned values and cannot represent these at all, which is a common source of errors when working with historical data or astronomical observations.

The epoch is an instant, not a local date. At the moment of timestamp 0 it was already 01:00 on 1 January 1970 in a zone at UTC+1, and still 31 December 1969 in New York, so a local date near 1970 can have a negative timestamp or a positive one depending on the zone.

Leap seconds and why they are ignored

Unix time treats the calendar as if every day had exactly 86,400 seconds, which means the count and the Earth's rotation slowly drift apart. Twenty-seven leap seconds were inserted between 1972 and the last one in 2016. When a leap second is announced, operating systems cannot make a day 86,401 seconds long without disturbing software that assumes 86,400, so they either repeat a second or spread the extra second across the day, which is called smearing.

The practical effect is small but not zero: subtracting two timestamps gives an interval one second shorter than the true elapsed time for each leap second inserted between them, so an interval from 1970 to today is 27 seconds short. Outside scientific and timing work this rarely matters. DateUtils follows the same convention and never counts leap seconds, as set out in its methodology.

The year 2038 problem

A signed 32-bit integer has a maximum value of 2,147,483,647. Counted in seconds from 1970, that value is reached at 03:14:07 UTC on 19 January 2038. One second later the count no longer fits, and a program that stores it in a 32-bit signed field wraps around to -2,147,483,648, which reads as 20:45:52 UTC on 13 December 1901.

The limitation is a property of the storage type, not of Unix time. Anything using a 64-bit integer is unaffected, and so is JavaScript, whose Date covers about 275,000 years either side of 1970. Systems still exposed are usually older embedded devices, 32-bit database columns and network protocols that define a 32-bit time field.

Converting between dates and timestamps

Converting a calendar date to a timestamp means counting the days since the epoch and multiplying by 86,400, then adding the time of day in seconds. The Unix timestamp converter works in both directions, for a date and time in any time zone.

When you convert a date that has no time attached, DateUtils uses midnight UTC. So 1 January 1970 becomes 0 and 15 March 2024 becomes 1710460800. Midnight in another zone is a different instant: midnight on 15 March 2024 in New York is 1710475200. A date on its own does not identify an instant; see time zones and daylight saving.

ISO 8601 as a readable form

Because raw timestamps are hard to read aloud or spot-check, they are often written in ISO 8601 format instead. The same instant as 1700000000 is 2023-11-14T22:13:20Z, where T separates date from time and Z marks UTC. Written in the same format and in UTC, ISO strings sort alphabetically in chronological order, which makes them convenient as file names, database keys and log lines. The date format converter shows this form for midnight UTC at the start of any date, and the time unit converter turns a number of seconds into minutes, hours, days or weeks.

One caution when reading ISO strings: without an offset, 2023-11-14T22:13:20 is a local time in some unspecified zone, while 2023-11-14 is a calendar date and does not denote an instant at all until a zone and a time are chosen.