Unix Timestamps Explained: What They Are and How to Convert Them
A practical guide to Unix timestamps — what epoch time means, seconds vs milliseconds, timezones, and how to convert between timestamps and dates.
Open any database schema and there’s a good chance you’ll see a column called created_at with a value like 1700000000. That’s a Unix timestamp — and if you’ve ever had to figure out what date it actually is, you know how quickly that gets tedious without the right tool.
The Timestamp Converter handles this in either direction: paste a number to get a human-readable date, or pick a date to get the epoch value back.
What is a Unix timestamp?
January 1, 1970 at 00:00:00 UTC is called the Unix epoch — the starting point. A Unix timestamp is just the number of seconds that have passed since then. At the time I’m writing this, the timestamp is around 1,716,000,000. In about 2038, 32-bit systems storing this value as a signed integer will overflow — that’s the Year 2038 problem, and it’s a real thing some legacy systems still need to handle.
The format has nothing to do with timezones. 1700000000 always means the same point in time, no matter where you are. That’s one reason it became the standard for storing time in databases and APIs.
Seconds vs milliseconds
Two formats get mixed up constantly:
- Seconds (10 digits):
1700000000 - Milliseconds (13 digits):
1700000000000
JavaScript’s Date.now() returns milliseconds. Python’s time.time() returns seconds (as a float). Databases vary. This mismatch causes bugs — you convert a timestamp and get a date in 1970 because your milliseconds were treated as seconds, or you get a date in 57,000 AD because it went the other way.
The Timestamp Converter auto-detects: anything above 10 billion is treated as milliseconds. That covers dates from 1970 through 2286, which handles practically every real-world case.
Timezones
Unix timestamps are timezone-neutral. The conversion to a human-readable time is where timezones enter the picture.
The tool shows three formats:
- ISO 8601 (
2024-11-14T22:13:20.000Z) — always UTC, the Z at the end is explicit about this - UTC — the same moment written in a more readable way
- Local — converted to your browser’s timezone
If your machine is set to UTC+3 and the UTC time is 19:00, your local time will show 22:00. This is working correctly — it’s just showing your timezone’s offset.
The “relative time” display
Seeing “3 years ago” next to 1560000000 is often more useful than the raw date when you’re scanning logs or debugging. The relative display updates to show how far in the past or future the timestamp is from the current moment.
Common use cases
Log files almost always use Unix timestamps for compactness. Paste the value and you get the full date — no mental math required.
API responses from services like Stripe, GitHub, or AWS use Unix timestamps in their JSON payloads. When debugging an expired token or a webhook timing issue, converting the timestamp is usually step one.
Database queries often need you to filter by time range using epoch values. Pick the start and end dates in the converter, grab the timestamps, and drop them into your WHERE clause.
Paste any timestamp into the Timestamp Converter and you’ll get the full date breakdown instantly — no account, no upload, nothing sent anywhere.