How to Convert a Unix Timestamp: Epoch Seconds, Milliseconds and the 2038 Problem

Somewhere in a log file, a database row or an API response sits a number like 1767225600, and the only question that matters is: what moment is that? The answer is a Unix timestamp — the count of seconds since the Unix epoch — and converting it by hand means calendar arithmetic nobody wants to do twice. Our free Unix timestamp converter works in both directions: paste an epoch timestamp to see the human-readable date in UTC and your local timezone, or pick a date and time to get its Unix timestamp. It auto-detects seconds versus milliseconds, and a one-click button grabs the current timestamp. This guide explains how to use it, what epoch time actually is, the worked example the tool itself uses, and the three traps — unit mix-ups, the 2038 problem and timezone confusion — that account for nearly every timestamp bug.

How to Use the Unix Timestamp Converter

Working timestamp to date: paste any epoch value into the first field — 10 digits for seconds or 13 digits for milliseconds — and the result appears instantly. The tool tells you which unit it detected, then shows the moment six ways: a plain-English UTC date, the ISO 8601 string developers paste into code, your browser's local interpretation, the timestamp restated in both seconds and milliseconds, and a relative label like "212 days ago" or "3 hours from now". The Use current timestamp button fills in the live epoch time so you can see exactly what "now" looks like as a number. Working date to timestamp: pick a calendar date and a time in the second section and the Unix timestamp appears below in seconds and milliseconds, with the UTC equivalent shown for confirmation. Times are interpreted in your local timezone — if you need the timestamp for midnight UTC instead, set the time field with your UTC offset in mind (for example, enter 19:00 while on US Eastern time in winter to hit 00:00 UTC). That local-timezone rule is the single most important thing to know about the second section, and the reason the UTC equivalent is shown next to every result: it lets you catch a timezone mistake before the timestamp ships into code.

What Is a Unix Timestamp? How It Works

A Unix timestamp — also called epoch time — counts the seconds elapsed since 00:00:00 UTC on January 1, 1970, the "Unix epoch". January 2, 1970 at midnight UTC is 86,400 (one day of 86,400 seconds); today the counter sits at about 1.79 billion. The genius of the format is that it is timezone-free: the number 1767225600 names one exact instant, and whether you are in New York, London or Sydney you convert it to your local wall-clock time the same way. The conversion itself is simple arithmetic: timestamp in seconds equals the date minus 1970-01-01 00:00:00 UTC, divided into seconds, and a date equals the epoch plus the timestamp in seconds. Two flavours exist. Seconds (10 digits) is the classic format used in databases, JWT tokens and most APIs. Milliseconds (13 digits) is what JavaScript's Date.now() returns and what many modern web APIs expect. Mixing them up is the most common bug in timestamp handling — a millisecond value read as seconds lands you in the year 58,000, while a second value read as milliseconds lands you in January 1970. This converter detects the unit from the digit count so a paste mistake is obvious immediately, before it becomes a bug report.

Worked Example: 1767225600

Take the timestamp 1767225600 and convert it step by step. Step one: detect the unit. Ten digits means seconds, so the value is 1,767,225,600 seconds. Step two: add to the epoch. 1970-01-01 00:00:00 UTC plus 1,767,225,600 seconds. Step three: convert to a date. 1,767,225,600 divided by 86,400 is 20,453 days after the epoch, which lands on January 1, 2026 at 00:00:00 UTC. Step four: reverse check. Converting 2026-01-01T00:00:00Z back gives 1,767,225,600 — the same number, which is the test every conversion should pass. Try it in the tool: paste 1767225600 and you will see January 1, 2026 at midnight UTC, plus your local equivalent — 7:00 PM on December 31, 2025 if you are on US Eastern Standard Time. Then use the date section to convert 2026-01-01 back and watch the same number come out. Round-tripping like this is the fastest way to confirm your code and your converter agree, and it is worth doing every time a timestamp crosses a system boundary: the round trip catches unit errors, timezone errors and off-by-one-day errors in a single glance, because any of them breaks the equality.

Seconds vs Milliseconds: The Mix-Up That Causes Most Timestamp Bugs

The unit mix-up deserves its own section because it causes more timestamp bugs than everything else combined. The rule is digit count: a 10-digit number is seconds, a 13-digit number is milliseconds, and anything else is probably a bug. When an API documents "timestamp", confirm which one — Stripe uses seconds, JavaScript's Date uses milliseconds, and plenty of Stack Overflow threads exist because someone divided by 1,000 twice. The two failure modes are unmistakable once you know them. A millisecond value read as seconds gives a date tens of thousands of years in the future: the year 58,000 is the signature of this bug. A second value read as milliseconds gives a date in January 1970, days after the epoch: the signature of the mirror-image bug. If your converted date is absurd, check the digit count before you check anything else. The converter helps twice over: it states the detected unit explicitly, and it restates every result in both seconds and milliseconds, so the number you paste into code is the number in the unit your system expects. The discipline to build is equally simple: whenever a timestamp enters your code, name the unit — epochSeconds, epochMillis, never bare "timestamp" — and the mix-up loses its hiding place.

The 2038 Problem and the Timezone Traps

The second trap is the 2038 problem. A signed 32-bit integer tops out at 2,147,483,647, and as a Unix timestamp in seconds that number is January 19, 2038 at 03:14:07 UTC. Systems that still store timestamps in signed 32-bit integers will overflow past that moment and wrap around to December 1901 — the same class of bug as the year-2000 problem, with a known date and a known fix (64-bit time), and the same lesson: a format choice made when a limit felt infinite becomes an emergency when the limit arrives. Modern 64-bit systems are unaffected, but embedded devices, old databases and legacy file formats still carry 32-bit time, and 2038 is now near enough that new systems should never introduce it. The third trap is timezones, and it is subtler because the timestamp itself has none. A Unix timestamp names an instant; a wall-clock time names an instant plus a timezone, and converting between them requires knowing which timezone you mean. The converter shows UTC and your local time side by side for exactly this reason, and its date-to-timestamp section interprets your input in your local timezone and shows the UTC equivalent for confirmation. The two classic errors are entering a UTC time while the tool assumes local (or the reverse), and forgetting daylight saving: a local time that does not exist on a spring-forward day, or exists twice on a fall-back day, has no single timestamp, and any converter must pick or flag one. When a timestamp and a date disagree by exactly your UTC offset, or by exactly one hour, you are looking at a timezone bug, not a data bug — and the fix is in the conversion, not the data.

Common Mistakes

Dividing by 1,000 twice (or never). Seconds to milliseconds is one multiplication; doing it twice, or forgetting it entirely, is the unit mix-up in code form. Name the unit in the variable and the bug has nowhere to hide. Assuming a timestamp carries a timezone. It does not. If two systems disagree about a timestamp by your UTC offset, one of them converted with the wrong timezone — the timestamp itself is innocent. Entering a UTC time into a local-time field. The date section interprets your input in your local timezone, so midnight UTC must be entered as 19:00 on US Eastern winter time. Check the UTC equivalent shown next to every result. Trusting a date without a round trip. Convert back and compare. A conversion that does not round-trip is wrong somewhere, and the round trip finds it in seconds. Storing new timestamps in 32-bit integers. The 2038 problem is a choice you make today, not a surprise waiting in 2038. Use 64-bit time for anything new. Reading a relative label as a precise time. "3 hours from now" is a convenience, not a measurement: it depends on the moment you looked, and it ages as you read it. For anything that matters, use the ISO 8601 string or the raw timestamp.

Limits Worth Knowing

Epoch time is a superb interchange format with honest limits. It has second (or millisecond) resolution in its common forms, so sub-millisecond precision needs something else; it counts seconds, not leap seconds, so it is not a perfect physical clock — UTC inserts leap seconds that epoch time simply does not count, and systems that need astronomical precision use different time scales. Dates before 1970 are negative timestamps, which some systems handle and some do not, so very old dates deserve a check rather than an assumption. Relative labels ("212 days ago") are computed against the moment you convert, so they go stale immediately — they are for orientation, not for records. And a timestamp tells you when, never why: a log timestamp of 1767225600 says January 1, 2026 at midnight UTC, and nothing about what happened then. Used with those limits in mind, the converter does one job well: it makes the number and the moment interchangeable, in both directions, with the unit stated and the timezone shown. That interchangeability is why epoch time became the default clock of computing, and why a converter that states its unit and shows both UTC and local time is worth more than a converter that merely converts. The companion guides for the same workflow are our time zone conversion guide, for the wall-clock side of the same problem, our hours-between-two-times guide, for durations between two moments, and our cron expressions guide, for scheduling things at the moments you just converted.

Frequently Asked Questions

More guides from ToolNest