Unix Timestamps Explained: Why Your Dates Are Off By an Hour (or a Day)

1704067200. That's a date, but you can't tell which one just by looking at it — and that's exactly why Unix timestamp bugs are so common. It's a plain integer with no unit, no timezone, and no format baked in, so every place that touches it has to agree on what it means. The moment one part of a system assumes seconds and another assumes milliseconds, or one assumes UTC and another assumes local time, dates start showing up a day early, an hour off, or sometime in 1970.

What a Unix Timestamp Actually Is

A Unix timestamp (also called epoch time) is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC — the "Unix epoch." 0 is that exact moment. 1704067200 is January 1, 2024, 00:00:00 UTC. Every second after the epoch just increments the number by one, with no concept of days, months, leap years, or timezones built into the number itself — those are all things you calculate from it, not part of it.

That's the appeal: two timestamps can always be compared or subtracted directly to get an exact duration, without worrying about calendar quirks like months having different lengths. It's also why almost every programming language, database, and API uses it internally, even if the interface shows you a human-readable date.

Seconds vs. Milliseconds — the #1 Source of Bugs

This is the mistake that catches the most people: Unix time is defined in seconds, but JavaScript's Date.now() and many APIs return milliseconds. Mix the two and you get a date off by a factor of 1000.

• 1704067200 (seconds) → January 1, 2024
• 1704067200 interpreted as milliseconds → January 20, 1970

If a "current timestamp" you're debugging shows a date in 1970, that's the tell — you're feeding a millisecond value into something expecting seconds. The fix is always the same: multiply by 1000 to go seconds → milliseconds, divide by 1000 to go milliseconds → seconds. Check what unit your specific language or API uses before assuming — Python's time.time() returns seconds (as a float), JavaScript's Date.now() returns milliseconds, and most SQL databases store seconds unless the column is explicitly typed otherwise.

The Timezone Trap

A Unix timestamp itself has no timezone — it's always relative to UTC. The bug happens when it gets converted to a human-readable date, because that conversion has to pick a timezone, and it's easy to pick the wrong one by accident.

1704067200 is:

• January 1, 2024, 00:00:00 in UTC
• December 31, 2023, 19:00:00 in US Eastern (UTC-5)
• January 1, 2024, 05:00:00 in Pakistan Standard Time (UTC+5)

Same number, three different calendar dates depending on which timezone renders it. This is why a timestamp that's "off by a day" almost always isn't a math bug — it's a display rendering in the wrong timezone, usually because the server's local timezone and the viewer's expected timezone don't match. The safest default for storing and logging timestamps is UTC everywhere internally, and only convert to a local timezone at the final point of display to a human.

The Year 2038 Problem

Older systems store Unix time as a signed 32-bit integer, which can only count up to 2,147,483,647 seconds after the epoch. That number is reached at 03:14:07 UTC on January 19, 2038 — after which a 32-bit signed timestamp overflows and wraps around to a negative number, which typically gets read as a date in December 1901. Most modern systems have already moved to 64-bit timestamps, which push the same problem out roughly 292 billion years, but older embedded systems, some database columns, and legacy 32-bit software are still exposed. If you're working with hardware or a codebase old enough to still use 32-bit time fields, this is a real migration to plan for, not a theoretical edge case.

Quick Conversions Worth Memorizing

Converting Without Doing the Math Yourself

Rather than hand-rolling the seconds/milliseconds and UTC/local-time conversion every time, Unix Timestamp Converter handles both directions instantly: paste a timestamp and get the UTC date, or pick a date and get the timestamp back, with a seconds/milliseconds toggle so you don't have to remember which one you need. It also shows the current timestamp live, which is the fastest way to sanity-check whether a value you're debugging is roughly "now" or something far off.

Quick FAQ

Why does my API return a timestamp like 1719440400000 instead of 1719440400? That's milliseconds, not seconds — three extra digits is the tell. Divide by 1000 before treating it as a standard Unix timestamp, or use it directly if your code already expects milliseconds (like new Date() in JavaScript).

Can a Unix timestamp be negative? Yes — negative values represent dates before January 1, 1970. Most systems support this correctly, but it's an edge case worth testing if your application handles historical dates.

Why do two servers show different times for the same timestamp? The timestamp itself is identical and correct — what differs is each server's local timezone setting used when displaying it. Check each server's configured timezone rather than assuming the timestamp is wrong.

Is Unix time the same as GMT or UTC? Unix time is a count of seconds, not a calendar time, but it's always calculated relative to UTC (which is effectively the same as GMT for this purpose) — there's no separate "Unix timezone."

Do leap seconds affect Unix timestamps? In practice, no — POSIX-defined Unix time ignores leap seconds and simply repeats or skips a second when one occurs, which keeps the day-to-day arithmetic simple at the cost of not being a perfectly continuous count of real elapsed seconds. This almost never matters outside of specialized timing systems.

Related Free Tools

• Unix Timestamp Converter — convert between epoch time and human-readable dates, seconds or milliseconds
• Cron Expression Generator — validate a schedule and see exactly when it'll run
• JSON Formatter — inspect API payloads that often carry timestamp fields
• Regex Tester — validate date and timestamp formats in your own data