1735689600 means nothing until you know it's a Unix timestamp: the number of seconds elapsed since January 1, 1970 at 00:00:00 UTC (the "epoch"). It's the most common date format in databases, APIs and JWTs — and also the source of one of JavaScript's most repeated bugs.
The three-zeros bug
Unix counts in seconds. JavaScript, on the other hand, builds dates from milliseconds:
new Date(1735689600) // ❌ 1970-01-21 — 50 years off!
new Date(1735689600 * 1000) // ✅ 2025-01-01
If your API returns seconds (like almost everything that isn't JavaScript: Python, PHP, SQL) and you pass that number straight into new Date(), you get a 1970 date. Multiply by 1000 — or if the value is already in milliseconds, don't — the mistake almost always goes in that direction.
Why UTC and not your local time
A Unix timestamp has no time zone: it's an absolute count of seconds, identical in Madrid and in Tokyo. The time zone only enters the picture when you display it — which is why two servers on different continents can compare timestamps directly with no fuss, and why it's the preferred format for created_at, a JWT's exp, or cache keys.
The Year 2038 problem
Systems that still store the timestamp in a signed 32-bit integer run out of numbers on January 19, 2038 (the infamous Y2038). It's the same kind of bug as Y2K, but it hits embedded systems, old databases, and the occasional time_t in C nobody's migrated to 64 bits yet. If you work with IoT or firmware, you should already be checking for it.
How to avoid the headache
Convert in both directions with the Unix timestamp converter: paste the number and see the date in your time zone and in UTC, or go the other way — pick a date and get the exact timestamp. If you need to compare the same moment across several cities, use the timezone converter; and if what you actually want is the number of days between two dates (not timestamps), the date difference calculator does the math without you having to subtract timestamps by hand.