Unix time is a single number that counts seconds since 00:00:00 UTC on January 1, 1970. That starting point is called the Unix Epoch, and it is the shared clock behind servers, databases, APIs, log files, schedulers, and plenty of apps you use every day [source: The Open Group].
TLDR: Unix time turns a date into a number, such as 1704067200, which means January 1, 2024 at 00:00:00 UTC. It is popular because computers compare and sort numbers faster than human date strings. A small analytics team processing 250,000 events per day can sort clicks, purchases, and errors cleanly by storing one timestamp field. The catch is that Unix time is usually in UTC, so you still need to convert it for local users.
Table of Contents
What Unix Time Means
Unix time, also called epoch time or POSIX time, is a timestamp format. It does not store “Tuesday” or “March” or “New York time.” It stores one plain count: the number of seconds that have passed since the Unix Epoch.
For example:
- 0 = January 1, 1970, 00:00:00 UTC
- 60 = January 1, 1970, 00:01:00 UTC
- 3600 = January 1, 1970, 01:00:00 UTC
- 86400 = January 2, 1970, 00:00:00 UTC
This makes time easy for machines. If one event has timestamp 1700000000 and another has 1700000100, the second event happened 100 seconds later. No month names. No regional date formats. No guessing.
Why January 1, 1970?
The date comes from the early Unix operating system. Unix needed a clean way to represent time, and its designers chose the start of 1970 in UTC as a convenient reference point. That choice stuck. Decades later, it still sits at the center of modern computing.
Honestly, it feels a bit strange that so much of current software depends on a date from 1970. Yet it works well. A single reference point keeps systems consistent, especially when data moves between time zones and countries.
Unix Time in Seconds, Milliseconds, and More
Standard Unix time is measured in seconds. But many systems use smaller units:
- Seconds: 1704067200
- Milliseconds: 1704067200000
- Microseconds: 1704067200000000
- Nanoseconds: 1704067200000000000
This causes a lot of annoying bugs. A timestamp in milliseconds is 1,000 times larger than one in seconds. If a tool expects seconds but gets milliseconds, your date may jump thousands of years into the future. Expect to waste time on that mistake at least once if you work with APIs.
A quick clue: if the timestamp has 10 digits, it is probably in seconds. If it has 13 digits, it is probably in milliseconds.
Examples of Unix Time Conversion
Here are simple examples of how Unix time maps to human dates:
| Unix Time | UTC Date and Time |
|---|---|
| 0 | 1970-01-01 00:00:00 |
| 946684800 | 2000-01-01 00:00:00 |
| 1609459200 | 2021-01-01 00:00:00 |
| 1704067200 | 2024-01-01 00:00:00 |
Suppose a website records a login at 1717243200. Converted from Unix time, that is June 1, 2024 at 12:00:00 UTC. If the user lives in Berlin, that may display as 14:00 in local summer time. If the user lives in New York, it may display as 08:00. Same moment. Different local labels.
How Developers Use Unix Time
Unix time shows up anywhere software needs order, timing, or expiration. Common uses include:
- Log files: recording when errors, requests, and background jobs happened.
- Databases: sorting records by creation time or update time.
- Authentication: setting expiration times for tokens and sessions.
- Analytics: grouping events into minutes, hours, days, or weeks.
- Scheduling: running tasks at a precise moment.
- Caching: deciding when stored data is too old to trust.
For a real case, picture an online store. A customer adds shoes to a cart, pays five minutes later, and receives an email ten seconds after payment. Unix timestamps let the system track that sequence without worrying about date wording. The database can subtract one number from another and get the delay in seconds.
Unix Time and Time Zones
Unix time is usually stored in UTC. That is a good thing. UTC avoids the mess of time zones during storage. The user interface can convert UTC into local time later.
This split matters. A company may have users in Tokyo, London, São Paulo, and Los Angeles. If the database stored local date strings only, reports would become messy fast. With Unix time, the system stores one neutral value. Then it displays the correct local time when needed.
Still, time zones bring pain. Daylight saving time changes can make a local hour repeat or vanish. A meeting at 02:30 may not exist on one spring date in some regions. Unix time avoids storing that confusion, but your app still has to display it correctly.
What About Leap Seconds?
Unix time usually ignores leap seconds. In most day-to-day programming, every day is treated as exactly 86,400 seconds. That is simple, but not perfectly aligned with Earth’s rotation.
For normal apps, this rarely matters. A shopping cart, blog post, invoice, or login form does not care about a one-second correction. For astronomy, telecom systems, scientific instruments, or high-precision trading, it can matter a lot. Those systems often use special time handling rules and should not rely on casual timestamp assumptions.
The 2038 Problem
The Year 2038 problem affects older systems that store Unix time as a signed 32-bit integer. The largest value such systems can store is 2,147,483,647. That points to January 19, 2038 at 03:14:07 UTC. One second later, the number can overflow and become negative.
Modern 64-bit systems avoid this issue for practical purposes. They can represent dates far beyond any normal software planning range. But old embedded systems, legacy databases, and forgotten devices may still carry the risk. It drives me crazy that old timestamp fields can hide quietly for years and then break at the worst possible moment.
Unix Time in Popular Programming Languages
Most programming languages make Unix time easy to read or create:
- JavaScript:
Date.now()returns milliseconds since the Unix Epoch. - Python:
time.time()returns seconds, often with decimals. - PHP:
time()returns seconds. - Java:
Instant.now().getEpochSecond()returns seconds. - SQL: many databases support Unix timestamp conversion functions.
Notice the JavaScript detail. It returns milliseconds, not seconds. That one difference causes endless off-by-1000 bugs. If you send JavaScript time to a backend, check the expected unit before saving it.
Best Practices for Using Unix Time
Unix time is simple, but it still needs care. Use these habits:
- Store timestamps in UTC. Convert only for display.
- Name fields clearly. Use names like
created_at_epoch_secondsorexpires_at_ms. - Keep units consistent. Do not mix seconds and milliseconds in the same column.
- Use 64-bit storage. Avoid old 32-bit limits.
- Format dates at the edge. Store numbers internally, show readable dates to users.
Unix time is not pretty to read, but that is not its job. Its job is to give computers a compact, reliable way to compare moments. Once you understand the Epoch, UTC, and the difference between seconds and milliseconds, the format becomes much less mysterious.