What Unix time actually is
Unix time is one running number: the count of seconds since midnight UTC on 1 January 1970. That starting instant is called the epoch, and every second since then adds one to the total. The big figure ticking at the top of this page is that count, live. You'll also see it called Epoch time or POSIX time, which are just different names for the same idea.
Because it's counted in UTC, the same instant carries the same Unix number everywhere on Earth. A server in Tokyo and a laptop in New York agree on the timestamp down to the second, with no time-zone math in between.
Why programmers reach for it
One number is easy for a computer to handle. It can store it, sort it, and do arithmetic on it without juggling calendars, time zones, or daylight saving rules. Want to know how long something took? Subtract the start timestamp from the end timestamp and you've got the gap in seconds. That's the whole trick, and it's why timestamps turn up in logs, databases, and APIs everywhere.
A raw string like 1782818700 isn't much use to a human, though. To read it, you convert it back into a normal date and time. Once you have that, you can line the moment up against any city on the world clock or shift it between regions with the time zone converter.
The Year 2038 problem
Unix time has one famous catch. Plenty of older systems stored the timestamp in a 32-bit signed integer, which tops out at 2,147,483,647. That ceiling gets hit at 03:14:07 UTC on 19 January 2038. When the count passes it, a 32-bit value wraps around to its largest negative number, so the clock suddenly reads a date back in December 1901. It's the same shape of bug as Y2K, just with a later deadline.
The fix is unglamorous but solid: store the number in a 64-bit integer instead. That has room for roughly 292 billion years, so it isn't running out. Most current systems already moved over, which is why this mostly threatens old, un-updated software rather than the device in front of you.
What about leap seconds?
Real-world time drifts a little because the Earth doesn't spin at a perfectly even rate, so UTC occasionally adds a leap second to stay lined up with it. Unix time mostly ignores that. It's meant to be a steady, linear count, so when a leap second lands it usually repeats or skips a second instead of tracking it exactly.
For everyday use that one-second gap never matters. It only comes up in work that needs extreme precision, like scientific measurement or high-frequency trading, where a single second is a long time.
Where you run into it
Once you know what to look for, Unix timestamps are everywhere:
- File systems: your operating system stamps when each file was created, changed, or opened.
- Databases: a tidy way to store dates, often in
created_atorupdated_atcolumns. - Web APIs: sessions, cache expiry, and request logs are usually tracked by timestamp.
- Programming: nearly every language can hand you the current timestamp and convert it to and from a readable date.
- Event logs: stamping each event keeps a precise, sortable record of what happened when.
If you just need to measure a stretch of time yourself rather than read a stored one, a quick countdown timer is the friendlier tool. Unix time is simply what the machines are using underneath.