Unix Timestamp Converter
Convert Unix timestamps to readable dates and back. Handles seconds, milliseconds, and microseconds automatically.
Runs entirely in your browserRelated Tools
What a Unix Timestamp Actually Is
A Unix timestamp counts the seconds elapsed since 1 January 1970 at 00:00:00 UTC, a moment known as the epoch. It is a single integer with no timezone, no calendar, and no formatting — which is exactly why it became the standard way for computers to exchange time.
Every ambiguity that plagues human date formats disappears. There is no confusion between 03/04 meaning March 4th or April 3rd, no daylight saving edge cases, no locale differences. The timestamp 1735689600 means the same instant to a server in Seoul and one in São Paulo. Only when it is displayed does a timezone enter the picture.
Seconds, Milliseconds, or Microseconds?
This is the single most common source of “my date says 1970” and “my date says the year 55000”. Different ecosystems count in different units:
- Seconds (10 digits) — Unix convention, PHP
time(), Pythontime.time(), most APIs, JWT claims - Milliseconds (13 digits) — JavaScript
Date.now(), Java, Kotlin, most JVM libraries - Microseconds (16 digits) — some databases and high-resolution logging
This tool infers the unit from the number of digits, which is reliable for any date in the modern era. If a date lands in 1970, you almost certainly fed a seconds value to something expecting milliseconds; if it lands thousands of years in the future, you did the reverse.
The 2038 Problem
Systems that store timestamps in a signed 32-bit integer run out of room on 19 January 2038, when the count exceeds 2,147,483,647 and wraps to a negative number — putting the date back in 1901. It is the same class of bug as Y2K, and it is real: embedded devices, old databases, and legacy C code are still affected.
Modern platforms use 64-bit timestamps, which push the limit roughly 292 billion years out. If you are writing new code, make sure the storage type is 64-bit and the problem never touches you.
Storing Time Correctly in an Application
Most timezone bugs come from storing a formatted local time and hoping. The rule that avoids nearly all of them is simple: store the instant, display the local time.
Keep timestamps in UTC — as a Unix integer or an ISO 8601 string with a Z suffix — and convert to the viewer’s timezone only at the moment of display. A stored value of “2025-01-01 09:00” with no zone is ambiguous the moment someone in another country reads it, and becomes wrong twice a year when daylight saving shifts.
The one genuine exception is future events tied to local wall-clock time. A meeting scheduled for 9am next March in Seoul should be stored as a local time plus a timezone identifier, not as a UTC instant, because if the timezone rules change before then the meeting should still happen at 9am local.
FAQ
Why does my timestamp show 1970?
You supplied seconds where milliseconds were expected. A 10-digit value read as milliseconds lands a couple of weeks after the epoch. Multiply by 1000, or let this tool detect the unit for you.
Do Unix timestamps have a timezone?
No, and that is the point. A timestamp is a count of seconds since a fixed instant in UTC. Timezones only apply when you format it for a human to read, which is why this tool shows both local time and UTC.
Do timestamps account for leap seconds?
Not really. Unix time pretends every day has exactly 86,400 seconds, so leap seconds are absorbed rather than counted. This makes arithmetic simple at the cost of being very slightly out of step with astronomical time.
Can a timestamp be negative?
Yes. Negative values represent dates before 1970 — -86400 is 31 December 1969. Not every system handles them correctly, so treat them with care.
Is anything sent to a server?
No. All conversion happens in your browser using its own clock and timezone settings.
Should I store dates as Unix timestamps or ISO 8601 strings?
Both are correct if they represent an unambiguous instant. Unix integers are compact and easy to compare; ISO 8601 strings are readable in logs and database dumps. What matters is that neither is stored as a local time without a zone.
Why do my times shift by an hour twice a year?
Daylight saving. A local time stored without a timezone becomes ambiguous when clocks change. Storing UTC and converting only for display removes the problem.
Why do two systems report different timestamps for the same event?
Usually because one is counting seconds and the other milliseconds, or because a local time was recorded without a timezone somewhere in the chain. Comparing the digit counts is the fastest way to tell which.
Is a timestamp of 0 meaningful?
It is exactly the Unix epoch, 1 January 1970 at midnight UTC. Seeing it in real data almost always means a value was missing and defaulted to zero rather than being a genuine date.
How do I get the current timestamp in code?
In JavaScript, Date.now() gives milliseconds and Math.floor(Date.now()/1000) gives seconds. In Python, time.time() gives seconds as a float. Mixing the two units between systems is the most common source of wrong dates.
⚠️ Reference Only
Output is generated based on your input and is provided for reference. Results may vary depending on your specific use case, edge cases, or environment-specific behavior. We do not guarantee accuracy of conversions, validations, or computed values.
Always verify critical outputs against official documentation or production environments. We are not responsible for any decisions or losses based on these tool results.