Unix Timestamps Explained (Epoch Time for Developers)
· 6 min read
Time is one of those things that looks simple until you have to write code around it. Unix timestamps are the foundation of how most systems track time, and a clear mental model of them will save you from a long list of subtle bugs.
What Epoch Time Is
A Unix timestamp is just a count: the number of seconds that have elapsed since the Unix epoch, which is midnight UTC on January 1, 1970. That is the entire concept. The number 1700000000, for example, is a specific instant in November 2023. Because it is a single integer with no timezone, no formatting, and no ambiguity, it is the ideal way to store and transmit a moment in time.
The value increases by one every second, everywhere on Earth, simultaneously. Two machines on opposite sides of the planet agree on the current Unix timestamp even though their wall clocks read different hours.
Seconds vs Milliseconds
Here is the trap that catches everyone at least once. Unix time is classically counted in seconds, but many environments use milliseconds. JavaScript's Date.now(), for instance, returns milliseconds since the epoch, while most databases, Linux tools, and APIs use seconds. The two differ by a factor of 1000.
A quick sanity check: a current seconds-based timestamp is ten digits, while a milliseconds-based one is thirteen. If your dates land in 1970 you almost certainly divided when you should have multiplied, or fed milliseconds into a function expecting seconds. When you need to inspect a value quickly, the Unix Time to Date converter shows you the human-readable instant so you can immediately tell whether the magnitude is right.
Timezones and UTC
A Unix timestamp has no timezone. It always represents an instant in UTC. Timezones only enter the picture when you display that instant to a person. The same timestamp renders as 9 AM in London and 4 AM in New York, but it is the identical moment.
The right architecture follows from this: store and compute in UTC timestamps, and convert to the user's local timezone only at the very edge, when rendering. Storing local times, or worse, mixing them, leads to off-by-an-hour bugs every time daylight saving shifts. Going the other direction, when you have a calendar date and want the underlying value, Date to Unix Time does the conversion and lets you reason about which timezone the input represents.
The Year 2038 Problem
Many older systems store Unix time in a signed 32-bit integer. The largest value that fits is 2147483647, which corresponds to 03:14:07 UTC on January 19, 2038. One second later, the counter overflows and wraps around to a negative number, throwing the system back to 1901. This is the Y2K of our era. The fix is to use 64-bit integers, which push the overflow billions of years into the future. Modern languages and platforms have largely moved to 64-bit time, but embedded systems, old file formats, and legacy databases may still carry the risk. If you work with long-lived systems, check your integer widths now.
ISO 8601: The Human-Friendly Counterpart
When you need a timestamp that is both machine-parseable and readable, ISO 8601 is the standard, looking like 2023-11-14T22:13:20Z. The trailing Z means UTC. Unlike a raw epoch number, ISO 8601 is self-describing and sorts correctly as plain text, which makes it excellent for logs and APIs. It is worth being fluent in moving between the two formats. The Timestamp Converter handles epoch, milliseconds, and ISO 8601 in both directions, all in your browser with nothing sent to a server, which is reassuring when the timestamps come from internal logs or private data.
Rules to Live By
- Store time as a UTC timestamp; convert to local only when displaying.
- Always know whether a value is in seconds or milliseconds.
- Use 64-bit integers to avoid the 2038 overflow.
- Use ISO 8601 for anything a human or another system needs to read.
Get these four habits right and an entire category of date bugs simply disappears from your codebase.