Timestamp Converter
Convert Unix timestamps to dates and back.
TIMESTAMP → DATE
DATE → TIMESTAMP
About Unix Timestamps
A Unix timestamp is the number of seconds (or milliseconds) elapsed since January 1, 1970 00:00:00 UTC (the Unix epoch). It's the standard way to represent time in databases, APIs, and log files.
FAQ
- Seconds vs milliseconds?
- Most Unix timestamps are in seconds. JavaScript uses milliseconds. Timestamps over 10 digits are almost always milliseconds.
- What is the Unix epoch?
- January 1, 1970 00:00:00 UTC. Timestamp 0 = that exact moment.
- What is the year 2038 problem?
- 32-bit signed integers max out at 2,147,483,647 — which is January 19, 2038. Modern systems use 64-bit integers and are not affected.
ABOUT THIS TOOL
Enter a Unix timestamp to see the equivalent human-readable date and time, or pick a date to get the timestamp back. Unix time counts seconds (or milliseconds, depending on the source system) elapsed since the Unix epoch of January 1, 1970 00:00:00 UTC, ignoring leap seconds — which is why it's the standard way computers store and compare dates internally. The converter also shows the value in your local timezone alongside UTC, since the same timestamp can display as a different date depending on where you are. Useful when reading server logs, debugging API responses, or working with date fields stored as numbers instead of readable strings.
HOW TO USE
- Paste a Unix timestamp (in seconds or milliseconds) into the input field.
- View the converted date and time in both UTC and your local timezone.
- Alternatively, pick a date and time using the date picker to get its timestamp.
- Check whether the tool detected your value as seconds or milliseconds — a 13-digit number is milliseconds, a 10-digit number is seconds.
- Copy the converted value you need.
- Repeat for other timestamps found in logs or API payloads.
COMMON USE CASES
- A backend developer reading raw server logs converts a createdAt field storing 1735689600 into a readable date.
- Someone debugging a scheduled job checks whether a cron timestamp matches the expected execution time in their timezone.
- A support engineer investigating a bug report converts the timestamp from an error report to see exactly when it occurred.
- A data analyst working with a CSV export full of epoch timestamps spot-checks a few rows before running a bulk conversion script.
- A developer testing token expiration logic checks what date a JWT's "exp" claim actually corresponds to.
TIPS & COMMON MISTAKES
- Unix timestamps in seconds are 10 digits (until the year 2286); if your number has 13 digits, it's in milliseconds, and mixing the two up is the most common conversion mistake.
- Unix time does not account for leap seconds, so it's not perfectly astronomically accurate, though this almost never matters for everyday applications.
- Timestamps are timezone-agnostic by definition — the number itself represents a fixed instant in UTC; only its display changes with timezone.
- Watch for the "Year 2038 problem": systems that store Unix time as a signed 32-bit integer overflow on January 19, 2038, which still affects some older or embedded systems.
MORE QUESTIONS
- What's the difference between a timestamp in seconds vs milliseconds?
- JavaScript's Date.now() and many web APIs use milliseconds since the epoch, while Unix/POSIX time and many backend languages default to seconds — a 10-digit number is seconds, 13 digits is milliseconds.
- What exactly is the Unix epoch?
- It's a fixed reference point, midnight UTC on January 1, 1970; all Unix timestamps represent the number of seconds (or ms) elapsed since that instant, with negative numbers representing dates before it.
- Does Unix time handle leap seconds?
- No, standard Unix time ignores leap seconds entirely, which means it drifts very slightly from true UTC over decades — a detail relevant to astronomers, not typical app development.
- Why does converting the same timestamp give different results on different computers?
- Only the UTC value is fixed; the human-readable local time shown depends on the timezone setting of the browser or system doing the conversion, so the same timestamp reads differently in Tokyo vs New York.