Unix timestamps, explained — what 1717000000 means and how to convert it
Where epoch time comes from, how to tell seconds from milliseconds at a glance, the 2038 problem, and how to convert timestamps both ways.
You're reading a log file or an API response and there it is: created_at: 1717000000. A big meaningless number where you expected a date. That's a Unix timestamp, and once you know the trick it's one of the simpler things in programming — but there are a couple of gotchas worth knowing so you don't misread one and ship a bug.
What the number is
A Unix timestamp is just the number of seconds since midnight UTC on January 1st, 1970 — a moment programmers call "the epoch." That's the entire idea. 1717000000 means "1,717,000,000 seconds after the start of 1970," which works out to late May 2024.
Counting from one fixed instant is a brilliantly simple way to store a moment in time. There's no timezone baked in, no date format to argue about, no ambiguity between 03/04 meaning March 4th or April 3rd. It's one integer, the same everywhere on Earth, and you only convert it to a human date — in whatever timezone you like — when you need to show it to a person.
Seconds or milliseconds? Read the length
Here's the gotcha that causes real bugs. Unix time comes in two common flavours, and they look almost identical until you count the digits:
- Seconds — what Unix systems and most backends use. A 10-digit number today.
- Milliseconds — what JavaScript's
Date.now()returns. A 13-digit number.
Mix them up and your date lands in 1970 (you treated milliseconds as seconds) or roughly the year 55,000 (you treated seconds as milliseconds). The quick tell is just the digit count — around 10 is seconds, around 13 is milliseconds. A good converter detects this automatically so you never have to think about it.
The 2038 thing, briefly
You may have heard of the "Year 2038 problem." Older systems stored the timestamp in a signed 32-bit integer, which runs out of room in January 2038 and rolls over to a negative number — a real Y2K-style issue for legacy code.
Modern systems use 64-bit integers and are fine for longer than the universe is likely to last, so it's not something you need to lose sleep over. But it's why you'll occasionally see it mentioned, and why some very old systems do strange things with far-future dates.
A related trap: timezones. A Unix timestamp has no timezone — it's an absolute instant. The timezone only enters when you display it. So the same timestamp is correctly "6 PM" for you and "9 PM" for someone three hours east. Bugs creep in when code converts to a local date too early and then compares it to a raw timestamp.
Converting either direction
Primova's Timestamp Converter goes both ways. Paste a timestamp and it gives you the date in your local time and in UTC, auto-detecting whether you handed it seconds, milliseconds, or microseconds. Or pick a date and get the timestamp back. There's a live "now" readout too, for when you just need the current epoch value to drop into a test.
It's all client-side and instant, with no math to do in your head. Next time a log throws a ten-digit number at you, the Timestamp Converter turns it into a real date in a second.