Why Is My Timestamp Off by an Hour? Unix Epoch Explained
You compared the same Unix timestamp in two places — a database log and a JavaScript console — and got two different-looking times. Nothing is broken. Here's what's actually going on with epoch seconds, milliseconds, and timezone display, and how to convert between them without guessing.
Short answerA Unix timestamp (epoch) is the number of seconds elapsed since January 1, 1970, 00:00:00 UTC. It's a single number with no built-in timezone — the timezone only enters the picture when you convert it back into a readable date.
Every operating system, database, and programming language that tracks "when something happened" tends to store it this way, because a plain integer is easy to compare, sort, and do math on. 1700000000, for instance, is always the same instant in time everywhere on Earth — it's only the label ("November 14, 2023, 10:13 PM" vs. "November 14, 2023, 5:13 PM") that changes depending on which timezone you're viewing it in.
Epoch, in one lineThe reference point — January 1, 1970, 00:00:00 UTC — from which all Unix timestamps count. Epoch 0 is that exact moment; negative numbers represent dates before 1970.
Why timestamps look "wrong" between apps
Short answerUsually the number is fine — the display timezone is what differs. One tool might render the epoch in UTC, another in your machine's local timezone, and a third in a hardcoded offset someone set years ago.
This is the single most common source of "timestamp confusion" reports in support tickets and bug trackers. The fix isn't to change the number — it's to pin down which timezone each side is displaying in, then compare like for like. A converter that lets you explicitly choose UTC, Local, or a fixed UTC± offset (rather than silently assuming one) removes the guesswork.
Epoch (seconds)
UTC
Example local (UTC-5)
1700000000
2023-11-14 22:13:20
2023-11-14 17:13:20
1735689600
2025-01-01 00:00:00
2024-12-31 19:00:00
Example values for illustration — the exact local time also depends on daylight saving rules for the date in question, so always check with a real IANA timezone rather than a fixed offset when precision matters.
Seconds vs. milliseconds (the classic bug)
Short answerA 10-digit epoch (e.g. 1752000000) is in seconds — the classic Unix unit. A 13-digit epoch (e.g. 1752000000000) is in milliseconds — what JavaScript's Date.now() returns by default. Treating one as the other lands on a wildly wrong date.
If a value gets passed to a date function expecting seconds but it's actually milliseconds (or vice versa), the result is either "already happened 50+ years ago" or "won't happen until the year 57683" — an easy tell that a units mismatch occurred. A converter that auto-detects the unit from digit count (and also recognizes 16-digit microsecond and 19-digit nanosecond values) saves you from mentally counting zeros every time.
Rule of thumb: 10 digits = seconds, 13 digits = milliseconds, 16 digits = microseconds, 19 digits = nanoseconds. If a "date" comes out around 1970 when it should be recent, you likely fed milliseconds into a seconds-only field — or the reverse.
The Year 2038 problem
Short answerOlder systems that store the epoch as a signed 32-bit integer will overflow after January 19, 2038, 03:14:07 UTC (epoch 2147483647) — the value wraps to negative, and the date appears to roll back to 1901.
This is often called "Y2038," a distant cousin of the Y2K bug. Modern 64-bit systems and most current databases and languages aren't affected, since a 64-bit signed integer can represent epoch values far beyond any practical need. Still, if you're working with older embedded systems, legacy 32-bit software, or file formats designed decades ago, it's worth confirming how timestamps are stored before assuming they'll keep working past that date.
Convert epoch seconds/milliseconds to a date (or back), in UTC, local, or a custom offset — plus bulk conversion, a live "now" counter, and relative date math.
A Unix timestamp (epoch) is the number of seconds that have elapsed since January 1, 1970, 00:00:00 UTC. It's a single, timezone-independent number, which is why it's used across operating systems, databases, and programming languages to represent a moment in time. For example, epoch 1700000000 corresponds to November 14, 2023, 22:13:20 UTC.
Why does my timestamp show the wrong time in a different app?
Usually it's not the timestamp that's wrong — it's the display timezone. The epoch number itself is fixed and timezone-independent; what changes is whether an app renders it in UTC, your local system timezone, or a hardcoded offset. If two tools disagree, check whether one is showing UTC and the other local time.
What's the difference between second and millisecond epoch values?
The second-based epoch (10 digits, e.g. 1752000000) is the classic Unix unit. The millisecond-based epoch (13 digits, e.g. 1752000000000) is what JavaScript's Date.now() and many web APIs use by default — it's 1,000 times the second value. Mixing the two up is one of the most common timestamp bugs, since a millisecond value treated as seconds lands in the year 57683.
What is the Year 2038 problem (Y2038)?
The Y2038 problem happens when older systems that store the epoch as a signed 32-bit integer overflow after January 19, 2038, 03:14:07 UTC (epoch 2147483647) — the number wraps to negative and the date rolls back to 1901. Modern 64-bit systems aren't affected because they can store much larger numbers.
How do I convert a Unix timestamp to a readable date?
Paste the epoch value into a converter tool; it should auto-detect whether the number is in seconds, milliseconds, microseconds, or nanoseconds based on its digit count, then show the readable date-time in your chosen timezone, plus ISO-8601 and RFC 2822 formats. To go the other way (date to epoch), enter a calendar date and time instead.
A note on this guide: the examples above use illustrative epoch values to show how UTC and local-time display can differ; actual local times also depend on daylight saving rules for the specific date. This article is informational and does not replace checking your own system or database timezone configuration.