Epoch Timestamp Converter
Convert Unix timestamps to readable dates and back. Auto-detects seconds vs milliseconds — the single most common source of off-by-1000 bugs.
Current time
Timestamp → Date
Date → Timestamp
Common intervals from now
How to use this tool
- The top panel shows the current Unix time, live, in both seconds and milliseconds.
- Paste any timestamp into Timestamp → Date. The tool detects whether you gave it seconds or milliseconds and tells you which — check that badge if a date comes out wrong.
- Use Date → Timestamp for the reverse. Dates typed as
YYYY-MM-DD HH:MM:SSare read in your local timezone. - Compare the UTC and Local rows whenever a bug might be timezone-related — a mismatch there is often the whole problem.
- Grab ready-made values from the intervals table for cache expiry, token TTLs, or test fixtures.
Unix time counts the seconds elapsed since midnight UTC on 1 January 1970. It has no timezone, no daylight saving, and no locale — it is a single integer that means the same instant everywhere on Earth. That simplicity is exactly why nearly every system stores time this way internally and converts to human formats only at the edges.
The overwhelmingly common bug is the factor of 1000. Unix time is defined in seconds, but JavaScript’s Date.now() returns milliseconds, as do Java’s System.currentTimeMillis() and most JVM APIs. Meanwhile Python’s time.time(), PHP’s time(), Go’s Unix(), and the exp claim in a JWT are all in seconds. Mix them and your timestamp lands in 1970 or in the year 57000. This converter auto-detects which you pasted and labels it, so the mistake becomes visible instead of silent.
A related trap is assuming a bare timestamp carries timezone information. It does not — it is always UTC by definition. When a date appears wrong by a few hours, the timestamp is almost never at fault; the display-layer conversion is. This is why the tool shows UTC and your local time side by side: if the UTC value is correct and the local value is what you expected to see stored, you have found your bug.
The famous Year 2038 problem comes from storing Unix time in a signed 32-bit integer, which overflows at 03:14:07 UTC on 19 January 2038 and wraps to 1901. Modern 64-bit systems are unaffected and will remain so for roughly 292 billion years, but embedded devices, legacy C code, and older database columns can still carry 32-bit time fields. If you work with long-dated records — mortgages, pensions, certificates — it is worth confirming the width of your time columns now rather than later.
For storage, prefer an integer timestamp or a timezone-aware type such as PostgreSQL’s timestamptz over a naive local-time string. Strings without offsets are ambiguous, sort incorrectly across timezones, and become genuinely unrecoverable during the hour that daylight saving repeats each autumn.
Frequently asked questions
Why does my timestamp convert to 1970 or to the year 57000?
A seconds-versus-milliseconds mismatch. A 10-digit value is seconds; a 13-digit value is milliseconds. Feeding milliseconds to a function expecting seconds throws the date far into the future; feeding seconds to one expecting milliseconds lands you just after 1970. This tool labels which it detected so you can spot the mismatch immediately.
Does a Unix timestamp have a timezone?
No. It is always the number of seconds since the 1970 epoch in UTC. Timezones exist only when you format it for display. If a date looks shifted by a few hours, the bug is in the formatting layer, not the timestamp.
What is the Year 2038 problem?
Systems storing Unix time in a signed 32-bit integer overflow on 19 January 2038 and wrap around to 1901. Anything 64-bit is fine. The residual risk sits in embedded firmware, old C code, and legacy 32-bit database columns — worth auditing if your data reaches past 2038.
How do leap seconds affect Unix time?
Unix time deliberately ignores them. Every day is treated as exactly 86,400 seconds, so during a leap second the counter repeats or stalls rather than incrementing. This keeps date arithmetic simple at the cost of being a fraction of a second off true astronomical time — irrelevant for almost all software, and handled by NTP smearing on most infrastructure.
Should I store dates as timestamps or as date strings?
Integers or a timezone-aware column type. Naive local-time strings are ambiguous, sort wrongly across regions, and are irrecoverable during the repeated hour when daylight saving ends. Store UTC, convert on display.