What Is Unix Time, and Why Do APIs Return Numbers Like 1700000000?

Dates as text are a mess for machines. Is 03/04/2026 the 3rd of April or March 4th? Does 2:30 PM mean Eastern, London, or Lahore time? Does a written date sort correctly — does the 9th come before the 10th when both are text? A single number sidesteps all of that. One integer sorts correctly, compares with a single greater-than check, subtracts cleanly to give a duration, and carries no timezone ambiguity at all, because the number itself means the same instant everywhere. The timezone only enters when a human wants to read it, and at that point the software converts the number into a local clock reading.

That is also why the number shows up in so many different places. A database stores created_at as an integer because integers are small, fast to index, and immune to date-format arguments. A log line records the epoch because the logging library gets the current time as a number for free. A login token carries an exp field as a number because the server that issued it and the server that checks it may sit in different timezones — comparing two numbers needs no timezone agreement at all. Even file systems record modification times this way under the hood. Whenever you see a bare 10-digit number near a date field, Unix time is the first explanation to test, and counting the digits is usually enough to confirm it.

There is a second, quieter reason: a number is language-neutral. A date written as November 14, 2023 only makes sense to an English reader, and a format like 14.11.2023 only makes sense to someone who knows the day-month order. The number 1700000000 needs no translation. The API sends the number, and each reader's software renders it in their own language and timezone. That split — one neutral value on the wire, local rendering at the edges — is the whole design idea, and it is why Unix time has survived for over fifty years while countless date formats have come and gone.

Start by counting the digits. A current timestamp in seconds has 10 digits; the same instant in milliseconds has 13. That single check resolves most confusion before it starts, because seconds and milliseconds are the two units you will actually meet. JavaScript's Date works in milliseconds, which is why browser code and many modern APIs emit 13-digit values, while older systems, databases, and JWT tokens mostly use seconds. If the number has 10 digits, treat it as seconds; if it has 13, treat it as milliseconds; if it has anything else, convert it explicitly rather than guessing, because old dates and far-future dates break the digit rule.

Four worked conversions, all verified

1700000000 seconds is 14 November 2023, 22:13:20 UTC. In Eastern time that is 5:13:20 PM on the same day — same instant, different clock reading, which is exactly the point of the system. The millisecond form of the same instant, 1700000000000, converts to the identical date and time; the extra three zeros are the only difference.

0 is 1 January 1970, 00:00:00 UTC — the epoch itself, the starting line everything is counted from. Negative numbers count backwards from it: -86400, minus one day in seconds, is 31 December 1969, 00:00:00 UTC. A negative timestamp is not an error; it is simply a date before 1970, and any converter that rejects it outright is hiding valid dates from you.

Two more anchors are worth memorising. 946684800 is 1 January 2000, 00:00:00 UTC — the Y2K midnight, useful as a sanity check when a value looks suspiciously round. And 1735689600 is 1 January 2025, 00:00:00 UTC, a recent round date you can use to test whether a converter is working: if it turns 1735689600 into anything other than the first instant of 2025 in UTC, the converter, not the number, is wrong.

Once you have a candidate date, sanity-check it against what you know. A created_at for an account made last week should land last week, not in 1970 and not in the year 55840. If it lands in either of those places, you have almost certainly mixed up seconds and milliseconds — which brings us to the traps.

Trap 1: Seconds vs milliseconds — the thousand-fold error

This is the single most common timestamp mistake, and it fails spectacularly in both directions. Feed the millisecond value 1700000000000 to a converter that assumes seconds, and you get the year 55840 — tens of thousands of years in the future, presented with a straight face. Feed the seconds value 1700000000 to JavaScript's Date, which expects milliseconds, and you land on 20 January 1970, three weeks after the epoch. Both errors look like nonsense dates, which is your clue: when a conversion gives you a date that cannot possibly be right, check the unit before you check anything else. Our converter names the unit it used in every result, so a wrong assumption is visible instead of silently wrong.

Trap 2: Comparing UTC against local time

Two people can look at the same timestamp and report different times, and both are right. The timestamp 1700000000 is 22:13:20 UTC and 5:13:20 PM Eastern; a colleague in Lahore reads it as 3:13:20 AM the next day. The classic debugging failure is comparing a UTC log line against a local-time screenshot and concluding the event happened five hours earlier or later than it did. The fix is a team habit, not a tool: agree on UTC whenever you report a time, and only convert to local time when you are describing what a person experienced.

Trap 3: Assuming every system uses the same unit

A JWT token's exp field is in seconds — that is what the standard specifies — but the JavaScript code reading it may work in milliseconds, and the database column storing it may use either. The unit is a property of the producer, not of Unix time itself, so never carry an assumption from one system into another. When you meet a new source, convert one known value first — a token you just issued, a row you just created — and confirm the unit against a date you already know before you trust any other value from that source.

Trap 4: The year 2038 limit in old storage

Systems that store Unix seconds in a signed 32-bit integer run out of room on 19 January 2038 at 03:14:07 UTC, when the count passes 2,147,483,647 and wraps around to a negative number — which reads as a date in 1901. That limit belongs to old 32-bit storage, not to Unix time itself: modern 64-bit systems handle dates far beyond 2038, and our converter does too. But it is worth knowing when you read old databases or embedded devices, where a timestamp near that maximum may genuinely overflow, or may already have been migrated to a wider format. If a date from an old system suddenly reads as December 1901, 2038 overflow is the first suspect.

Trap 5: Leap seconds, and the day that is not quite a day

Unix time counts every day as exactly 86,400 seconds and does not insert extra seconds for leap seconds, the occasional one-second adjustments that keep civil time aligned with the Earth's rotation. In practice this means Unix time sits 27 seconds away from a leap-second-aware atomic count — 27 leap seconds have been inserted since 1972, most recently at the end of 2016 — but it never produces a day with 86,401 seconds, and date arithmetic on it stays simple. Unless you are doing astronomy or satellite work, this is a curiosity, not a trap to guard against; but it is the reason a timestamp converted to the second may differ by a few seconds from a leap-second-aware clock, and why you should not use Unix timestamps as proof of an exact second in a legal or scientific dispute without checking the source's leap-second handling.

Suppose a support ticket contains a log line with a user ID, an internal URL, and a timestamp of 1700000000, and the user says something went wrong around 5 PM Eastern on 14 November 2023. Here is the workflow, in order:

1. Copy only the number, not the whole log line. Log lines often sit next to tokens, session IDs, and internal URLs, and pasting the full line into a random converter site hands all of that to a stranger. Our converter runs entirely in your browser, so nothing you paste leaves your device — but the habit of copying just the number protects you everywhere else too.
2. Count the digits. Ten digits means seconds, thirteen means milliseconds. If the value is ambiguous, set the unit explicitly rather than letting a tool guess.
3. Convert and read UTC first, then local time. For 1700000000 that gives 22:13:20 UTC and 5:13:20 PM Eastern — which matches the user's report, so the timestamp is consistent with their story and you can move on to the actual bug.
4. Convert back as a check. Pick the date you got and convert it to Unix time again; you should land on the exact number you started with. A round-trip that does not return the original number means the unit or the timezone handling is wrong somewhere, and you have caught it before it misled an investigation.
5. If the timestamp arrived inside JSON, format that JSON first with our JSON Formatter so you can see which field is which, and if it arrived inside an encoded token, decode the payload with our Base64 Encoder & Decoder before converting — the timestamp fields in a JWT payload are seconds, and they are the ones that tell you when the token expires.

One more practical note: timestamps are also how you build realistic test data. When you need a set of fake users with plausible creation dates, generate the IDs with our UUID Generator and pick the timestamps from real calendar dates with the converter, rather than inventing numbers by hand — hand-invented timestamps are how a test fixture ends up dated in 1970 or 55840 and wastes an afternoon. If you want the background on the format those timestamps usually travel in, read What Is JSON?.

Why 1 January 1970?

Unix was developed around 1969 and 1970, and 1 January 1970 was picked as a convenient round starting point near the system's birth — early enough to cover the computing era, late enough to keep the numbers small. There is nothing astronomically special about the date; it is a convention the whole industry agreed on, and that agreement is what makes it useful.

Is Unix time the same everywhere on Earth?

Yes. The number for a given instant is identical in every timezone, because it counts seconds from one fixed instant, not clock readings. Timezones only change how that instant is displayed to a human. That is why servers store the number and convert it for display, rather than storing the display text.

Why do JavaScript timestamps have 13 digits?

Because JavaScript's Date measures time in milliseconds, not seconds, so the same instant needs three extra digits. A current JavaScript timestamp is the seconds value with 000 appended. When moving between JavaScript and a seconds-based API, multiply or divide by 1,000 — and check the digit count after every conversion, because a missed factor of 1,000 is trap 1 in disguise.

Should I worry about the year 2038 problem?

Only if you work with old 32-bit systems. Modern 64-bit software, browsers, and databases handle dates far beyond 2038, and the count in 64-bit seconds would not overflow for hundreds of billions of years. The risk is confined to legacy embedded devices and old databases still storing timestamps in a signed 32-bit integer — if you meet one, migrate the storage format rather than patching around it.

Do leap seconds break Unix timestamps?

No. Unix time simply does not count leap seconds: every day is exactly 86,400 seconds, so date arithmetic stays simple and timestamps never produce a 61-second minute. The trade-off is a drift of a few seconds against astronomical time, which matters for astronomy and satellite work but not for logs, tokens, or database records.