Unix Time, Explained: Epoch Seconds, Timezones and the ISO Formats

Sooner or later every developer stares at a number like 1750982400 in a log file or a database column and has to figure out what moment in time it represents. That number is a Unix timestamp, one of the most quietly universal conventions in computing — it’s how databases store dates, how APIs put a time on the wire, and how cron decides whether a job is due. It looks opaque, but the idea behind it is almost embarrassingly simple, and once you understand it you can read these numbers at a glance.

One number: seconds since the epoch

A Unix timestamp is just the number of seconds that have elapsed since midnight UTC on 1 January 1970. That instant — 1970-01-01T00:00:00Z — is called the Unix epoch, and it’s the zero point everything counts from. Timestamp 0 is the epoch itself; timestamp 86400 is exactly one day later (60 × 60 × 24 = 86,400 seconds in a day); timestamp 1750982400 is some moment in June 2026.

The genius of this design is that a point in time becomes a single integer. There’s no month, no timezone, no daylight-saving ambiguity baked into the value — just a count of seconds. That makes timestamps trivial to store, sort, and subtract. Want to know how long between two events? Subtract their timestamps and you get the gap in seconds, no calendar arithmetic required. The Unix Timestamp Converter turns any such integer into a human-readable date and back again, and shows the relative distance (“3 days from now”, “2 hours ago”) computed by exactly that subtraction.

Seconds or milliseconds? Watch the digit count

Here’s the single most common source of bugs: not everything counts in seconds. Unix tools and most backends use seconds, but JavaScript’s Date, Java’s System.currentTimeMillis(), and many APIs use milliseconds — a thousand times bigger. Feed a seconds value into something expecting milliseconds and your date lands in January 1970; do the reverse and you’ll be in the year 57,000.

The quick tell is length. A seconds timestamp for “now” in the 2020s has 10 digits; the millisecond version has 13. If you see 1750982400 it’s seconds; 1750982400000 is milliseconds. The converter reports both forms for any input and is forgiving about which you paste in, so you can sanity-check a value the moment you encounter it.

The timestamp is UTC — the timezone comes later

A frequent misconception is that a timestamp “is” in some timezone. It isn’t. The count of seconds since the epoch is absolute — it refers to the same instant everywhere on Earth. The timezone only matters when you render that instant as a wall-clock date for a human.

So 1750982400 corresponds to one specific moment, but whether that displays as a Friday evening in Tokyo or a Friday morning in New York depends entirely on the zone you format it in. This is why storing timestamps (or UTC) and converting to local time only at display is the universally recommended practice — the stored truth never shifts, and daylight-saving transitions become a formatting concern rather than a data-corruption risk. The converter lets you pick any IANA timezone and shows the same underlying instant rendered in that zone, with the correct UTC offset, so you can see directly that one integer maps to many local wall-clock readings.

ISO 8601 and RFC 3339: the human-readable forms

When a timestamp does need to be written for humans (or for interoperable APIs), it’s usually rendered as ISO 8601 — 2026-06-27T00:00:00Z — where the Z (“Zulu”) means UTC. RFC 3339 is a tightened, internet-focused profile of ISO 8601 that’s stricter about format and lets you write an explicit offset like 2026-06-27T09:00:00+09:00 instead of Z. For almost all practical API work the two are interchangeable, and the year-month-day-then-time ordering has a lovely property: sorting these strings alphabetically also sorts them chronologically. The converter emits ISO 8601 in UTC and RFC 3339 in your chosen zone, alongside the raw seconds and milliseconds, so you can copy whichever format the system you’re feeding actually wants.

A couple of edge cases worth knowing

Two quirks are worth keeping in your back pocket. First, the year 2038 problem: systems that store the timestamp in a signed 32-bit integer run out of room at 2147483647, which falls on 19 January 2038. Past that the counter overflows into negative numbers and dates wrap to 1901. Modern systems use 64-bit timestamps and are fine for billions of years, but legacy embedded code is still being patched. Second, Unix time politely ignores leap seconds — it pretends every day is exactly 86,400 seconds long, which keeps the arithmetic clean at the cost of being a hair off from astronomical time during the rare leap-second insertion.

None of this requires you to do the math by hand. Paste an epoch value — seconds or milliseconds — into the Unix timestamp converter to read it as a date in any timezone, or enter a date to get the timestamp back, complete with ISO 8601, RFC 3339, day-of-year, and ISO week number. The next time a ten-digit number shows up in a log, you’ll know exactly what it means.