Unix time is a way of representing a moment as a single number: the count of seconds that have elapsed since 00:00:00 UTC on Thursday, 1 January 1970, a reference point known as the Unix epoch. It treats every day as exactly 86,400 seconds and ignores leap seconds. Unix and Linux systems, most programming languages, databases, log formats and web APIs use it, or a millisecond variant, because one integer is easy to store, compare and calculate with.
At a glance
- A Unix timestamp is a count of seconds since the epoch, 00:00:00 UTC on 1 January 1970; earlier moments are negative numbers.
- It is time-zone neutral: the same instant has the same value everywhere, and local time is applied only on display.
- Leap seconds are not counted, so Unix time is not a strict count of every elapsed second.
- Many systems use milliseconds, microseconds or nanoseconds since the same epoch, so the unit has to be known before a value can be read.
- Stored in a signed 32-bit integer, Unix time overflows in January 2038, which is the Year 2038 problem.
What problem it solves
Computers need to record when things happen in a form that is compact, unambiguous and easy to compare. Human date formats are none of those: they vary by country, depend on time zones and daylight saving, and are slow to sort and subtract. Unix time replaces all of that with one number. To find which of two events came first, compare the numbers. To find how long something took, subtract them.
For buyers, Unix time usually appears in three places: log files and security events, data exports and API responses, and conversations about the Year 2038 problem (Y2K38). Knowing what the number means makes it easier to correlate events across systems and to judge whether a vendor’s answer about date handling holds up.
How it works
Counting. A system clock keeps time in UTC, usually synchronized with network time servers. When software asks for the current Unix time, it gets the number of seconds since the epoch. For example, 1,000,000,000 fell on 9 September 2001 at 01:46:40 UTC.
Leap seconds. UTC occasionally inserts a leap second to stay aligned with the Earth’s rotation. Unix time does not count it, because it defines every day as 86,400 seconds. Systems handle the extra second by repeating a timestamp, stepping the clock or “smearing” the difference across several hours, which is why two systems can briefly disagree.
Precision. The classic form is whole seconds. Many languages and APIs use milliseconds since the epoch, and some databases and tracing tools use microseconds or nanoseconds. A 10-digit number is usually seconds and a 13-digit number milliseconds, but the documentation should say.
Storage size. On older systems the seconds count was stored in a signed 32-bit integer, which holds values up to 2,147,483,647, reached at 03:14:07 UTC on 19 January 2038. Modern 64-bit systems generally store it in a 64-bit integer, which is large enough for any practical date.
Conversion. Displaying a Unix timestamp as a calendar date requires applying a time zone and its daylight saving rules, which is where many reporting and correlation errors creep in.
When it matters for buyers
- Log analysis and incident response. Log management and SIEM tools correlate events from many sources. If sources mix seconds and milliseconds, or apply local time zones inconsistently, the timeline of an incident can be wrong.
- Data integration and exports. When moving data between platforms, confirm how each system stores and exports timestamps, including precision and time zone.
- Long-lived devices and software. Anything that stores Unix time in 32 bits carries the 2038 limit, the modern descendant of the Year 2000 problem (Y2K).
- Monitoring and observability. Metrics and traces depend on accurate, synchronized timestamps. Our application performance monitoring and observability page covers how buyers compare tools that rely on them.
Questions to ask vendors
- In what format and precision does your product store and export timestamps: seconds, milliseconds or finer, and as Unix time or a text date?
- Are timestamps stored in UTC, and how are time zones applied in reports and exports?
- Is time stored in a 64-bit field throughout the product, including firmware, databases and APIs?
- How does the product synchronize its clock, and how does it handle leap seconds?
- When ingesting logs from other systems, how do you detect and normalize mixed time formats?
How it differs from ISO 8601 date strings
Unix time and ISO 8601 describe the same moments in different ways. Unix time is a single number of seconds since the epoch, compact and easy to compute with but unreadable to people. ISO 8601 is a text format, such as 2038-01-19T03:14:07Z, that people can read and that can carry a time zone offset. Many APIs and exports use ISO 8601 for readability, while systems often store Unix time internally and convert when they display or exchange it.