Unix Timestamp Converter

What is a Unix timestamp?

A Unix timestamp is a single number: how many seconds have passed since midnight on January 1, 1970, in UTC. That moment is called the Unix epoch, and it's the zero point that every Unix-like operating system, most programming languages, and most APIs use to talk about time without arguing over time zones, calendars, or date formats.

The appeal is the simplicity. A date like "March 14, 2023" needs context — which time zone, which calendar system, which format (US, European, ISO)? A timestamp like 1678751600 needs none of that. It's a count. Add seconds, subtract seconds, compare with < and > — the math works the same everywhere.

Worked example: paste 1700000000 into the converter and the output is Tue, 14 Nov 2023 22:13:20 UTC. That's the human reading of one billion seven hundred million seconds after the epoch. Run it the other way: pick November 14, 2023 at 22:13:20 UTC in the date picker and the converter gives you 1700000000 back. Round trip, no loss.

When you'll use the Unix Timestamp Converter

If you've ever opened a server log and seen 1709856000 in the "created" column, or read a webhook payload with "timestamp": 1712054400, or queried a database where expires_at is just an integer — you've already hit the moment this converter is for. You need the human date, fast, and you don't want to write a one-line script to do it.

• Backend developers reading API responses where dates arrive as Unix integers (Stripe, GitHub, AWS, almost every JSON API)
• DevOps and SREs reading log files where every line starts with a timestamp
• Database engineers inspecting created_at / updated_at / expires_at columns stored as integer seconds
• Mobile developers debugging push notification payloads or analytics events
• Anyone working with cookies, JWT tokens, or cache TTLs — all of which carry expiration timestamps
• QA engineers verifying that a "created 3 minutes ago" UI is showing the right thing relative to the timestamp in the response

The converter goes both ways: timestamp to date, date to timestamp. The second direction is useful when you're writing a test fixture, seeding a database, or curling an API that needs a specific moment in time as a number.

Seconds vs milliseconds — the format gotcha

Unix timestamps come in two flavors. Classic Unix uses seconds since the epoch. JavaScript uses milliseconds since the epoch (so a JavaScript timestamp is the Unix value times 1000). The converter handles both: if your input is 13 digits or longer, it's treated as milliseconds; 10 digits or fewer is treated as seconds.

This trips people up constantly. A backend in Go or Python typically gives you seconds (time.Now().Unix()). A backend in JavaScript or Node typically gives you milliseconds (Date.now()). If you copy a value from one side to the other without converting, you'll either land on January 1, 1970 (you treated seconds as milliseconds, dividing the value by 1000) or thousands of years in the future (you treated milliseconds as seconds).

Worked example: a server returns {"created": 1700000000} and you check it in a JavaScript console with new Date(1700000000) — you get January 20, 1970, not November 2023. The fix is new Date(1700000000 * 1000). The converter does this multiplication automatically based on the digit count, so you don't have to think about it.

The Y2038 problem

Unix timestamps were originally stored as signed 32-bit integers. A signed 32-bit integer can hold values from -2,147,483,648 to +2,147,483,647. That upper bound corresponds to 03:14:07 UTC on January 19, 2038. One second later, a signed 32-bit timestamp overflows — wraps around to a negative number — and the system thinks it's December 1901.

This is called the Y2038 problem, or the "Year 2038 bug," and it's a real concern for any system still using 32-bit time. Embedded devices, old C codebases, some filesystems, some database column types — all candidates. Modern Linux kernels switched to 64-bit time_t years ago. Java, Python, JavaScript, and Go all use 64-bit integers (or higher) for timestamps natively. A 64-bit signed timestamp can represent dates roughly 292 billion years past or future, which is plenty.

If you're storing timestamps in your own database, check the column type. PostgreSQL integer is 32-bit (vulnerable); bigint is 64-bit (safe). MySQL INT is 32-bit; BIGINT is 64-bit. If you've inherited a system with a 32-bit timestamp column and your records will be alive past 2038, that migration is worth scheduling now while the deadline is still a decade out.

Notable Unix timestamps to know

A few timestamps are worth recognizing on sight — they show up in test fixtures, demo data, and sometimes in bug reports:

If you see 0 in a date field, somebody forgot to assign a value. If you see 2147483647, somebody used "max int" as a "never expires" sentinel — fine for now, dangerous after 2038.

How the converter handles time zones

Unix timestamps don't have a time zone. The number 1700000000 is the same instant everywhere on earth — it represents the exact same moment whether you're in Tokyo, London, or São Paulo. What changes between locations is the calendar reading of that instant.

The converter displays UTC by default because that's the unambiguous reading. If you need the local time zone, the easiest move is to convert to UTC here and then translate to your local zone in your code or in a spreadsheet (Google Sheets has a EPOCHTODATE function; Excel needs (A1/86400) + DATE(1970,1,1)).

UTC vs GMT: the values are identical in practice; UTC is the technical name (Coordinated Universal Time), GMT is the older British name (Greenwich Mean Time). Use either; people understand both.

Tips and gotchas

A handful of corner cases worth knowing about when you're staring at timestamps in the wild:

• Leap seconds aren't counted. Unix time pretends every day has exactly 86,400 seconds. Real UTC inserts occasional leap seconds to keep clocks aligned with Earth's rotation. The difference is at most a few seconds and most code ignores it.
• Negative timestamps are valid. A negative number means "before 1970." -1000000000 is March 1938. Some date libraries refuse negative values; the converter accepts them.
• Scientific notation in JSON. Some serializers emit timestamps as 1.7e9 instead of 1700000000. Convert to integer form first; the converter expects digits.
• Microseconds and nanoseconds. Some systems (Kafka, Cassandra, Go's time.Now().UnixNano()) use microsecond or nanosecond precision — 16 or 19 digits respectively. Trim to milliseconds (drop the trailing zeros or divide by 1000) before pasting.
• Floating-point timestamps. Some languages (Python's time.time()) return a float like 1700000000.123456 — seconds with a fractional part. The converter rounds; if you need sub-second precision, save it elsewhere.

Related Microapp tools

Once the timestamp is converted, you might want to do something with the date. A few tools that pair well:

• Date Time Calculator — add or subtract hours, days, weeks, or years from a date. Useful when you need to compute an expiration timestamp ("now plus 30 days") for a token or cookie.
• Age Calculator — get the exact age in years, months, and days between two dates. Handy when a record's timestamp is a birthdate and you need the current age.
• Days Between Dates — count the days between two timestamps. Often the answer you actually wanted when you started converting timestamps.

Frequently asked questions

Why does the timestamp converter show UTC instead of my local time?

Unix timestamps don't carry a time zone — they're an absolute count of seconds since a fixed point in 1970 UTC. UTC is the unambiguous reading. Showing local time would mean guessing at your time zone, and the guess would be wrong for half the people who use this tool. If you need local time, convert to UTC here and apply your zone offset in your code or spreadsheet.

Why is my timestamp giving me January 1970 as the result?

You're probably looking at a small number (under 10,000 or so) that was meant to be a millisecond timestamp but is being read as seconds. Or you're looking at 0, which is the literal Unix epoch — usually a sign of an uninitialized field in a database or an empty value in a serializer. Check whether the number has 10 digits (seconds) or 13 digits (milliseconds).

What's the difference between a Unix timestamp and an ISO 8601 date?

A Unix timestamp is a single integer (1700000000). An ISO 8601 date is a human-readable string (2023-11-14T22:13:20Z). They represent the same instant — just different formats. APIs typically use one or the other; some use both. ISO 8601 is more readable; Unix timestamps are smaller and easier to compare.

How do I get the current Unix timestamp in my programming language?

Most languages have a one-liner. JavaScript: Math.floor(Date.now() / 1000). Python: int(time.time()). Go: time.Now().Unix(). Rust: SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs(). Bash: date +%s. All return seconds since the epoch (except JavaScript's Date.now(), which returns milliseconds — divide by 1000).

Is the Y2038 problem actually going to break things?

For 64-bit systems running modern operating systems and modern languages: no. Those have used 64-bit time integers for years. The risk is in old embedded systems (IoT devices, cars, industrial controllers), legacy C code, and database columns typed as 32-bit integers. If your system is still alive in 2038 and any of those describe it, plan a migration before then. There's no panic — the bug is fully understood and the fix is straightforward — but it's not a hypothetical either.

Can a Unix timestamp be a decimal number?

Yes. Some languages (Python, R) return floats by default — 1700000000.123456 represents seconds with microsecond fractional precision. Most database columns and JSON APIs use integer seconds and drop the fraction. The converter accepts decimals but treats the fractional part as fractional seconds; the displayed date is rounded to the nearest second.

Why use Unix timestamps instead of just storing dates as strings?

Math. Comparing "2023-11-14T22:13:20Z" to "2023-11-14T22:13:21Z" as strings happens to work because ISO 8601 sorts correctly as text. But "2023-11-14T22:13:20-05:00" compared to "2023-11-14T22:13:20Z" as strings is wrong — those are different instants but compare equal in a string sort. Integer timestamps don't have this problem. They also take less space and index faster in databases.

Does the converter work offline?

Yes. The conversion runs entirely in your browser using the built-in Date object. No server round trip, no API call, no analytics on what timestamps you're converting. The page works fine with your network disconnected once it's loaded.