How does the tool know if my number is seconds or milliseconds?

By magnitude: current-era timestamps have 10 digits in seconds and 13 in milliseconds, so the digit count identifies the unit. Ambiguity only exists for dates near 1970 or far future — if the result looks wrong, check the unit explicitly with the Epoch Converter tool.

What timezone is a Unix timestamp in?

None — it counts seconds since 1970-01-01T00:00:00 UTC and identifies the same instant worldwide. Timezone applies only when formatting it into a human date. Store UTC/timestamps; localize at display time.

Why do I get 'Invalid Date' for my date string?

The string doesn't match a parseable format. Safest input is ISO 8601 (2026-07-08T14:30:00Z or with ±hh:mm offset). Ambiguous formats like 03/04/2026 depend on locale (March 4 vs April 3) and are best avoided entirely.

Is the year 2038 problem still real?

For 64-bit systems, no — they are safe for ~292 billion years. It persists in embedded/IoT devices, old file formats, and MySQL's legacy TIMESTAMP column. New designs should simply avoid 32-bit second counters.

Do Unix timestamps include leap seconds?

No. Unix time defines every day as 86,400 seconds; leap seconds are smoothed over (Google/AWS smear them across the day). Consequently Unix time is about 27–37 seconds off TAI — irrelevant for business software, disqualifying for high-precision science.

Can timestamps be negative or zero?

Yes: 0 is the epoch itself and negative values are pre-1970 dates (-86400 = Dec 31, 1969). Both are valid; watch for code that treats 0 as 'no value' and parsers that refuse negatives.

Timestamp Converter | Time Tools

About Timestamp Converter

A Unix timestamp counts seconds since the epoch: 1970-01-01T00:00:00 UTC. It is how databases, logs, JWTs, and APIs store time — a single unambiguous number, immune to time zones and date formats. Humans, however, read 2026-07-08T14:30:00+07:00 far better than 1783150200. This converter translates both directions: paste a timestamp to get a readable date (ISO 8601, UTC, or local), or paste a date string to get the timestamp.

It accepts seconds and milliseconds automatically (detected by digit count), plus common date formats. Everything runs locally in your browser.

How to use Timestamp Converter

Enter a Unix timestamp (seconds or milliseconds) or a date/time string.
The tool converts between formats and shows human-readable date and time.
Use the output for your target system or locale.

Example

Input

Your input or data here

Output

Result will appear here after running the tool

Seconds vs milliseconds — the 10-vs-13-digit rule

The single most common timestamp bug is a factor of 1000. Unix convention is seconds (10 digits for current dates: 1783150200), but JavaScript's Date.now() and Java's System.currentTimeMillis() return milliseconds (13 digits: 1783150200000). Feed milliseconds where seconds are expected and you get a date around the year 58,000; feed seconds where milliseconds are expected and you land in January 1970.

The digits give it away instantly: 10 digits = seconds, 13 = milliseconds, 16 = microseconds (common in database columns and Python's time.time_ns()/1000), 19 = nanoseconds (Go, some tracing systems). If a converted date is wildly wrong, count digits before anything else.

Time zones: timestamps don't have one

A Unix timestamp is a point on the UTC timeline — the same number everywhere on Earth. Time zones only enter when rendering it as a wall-clock date. 1783150200 is simultaneously 07:30 UTC, 14:30 in Bangkok, and 03:30 in New York; all three are the same instant. Confusion arises when a date string without an explicit offset (2026-07-08 14:30) gets interpreted in different zones by different systems — that string names a different instant in each zone.

Rules that prevent 90% of timezone bugs: store timestamps or UTC everywhere; convert to local time only at the display edge; and always include the offset when serializing dates as strings (2026-07-08T14:30:00+07:00, ISO 8601). Note ISO 8601's 'Z' suffix means UTC exactly.

Edge cases worth knowing

Year 2038: 32-bit signed seconds overflow on 2038-01-19T03:14:07Z. Modern 64-bit systems are fine, but embedded devices and old schemas (MySQL TIMESTAMP caps at 2038) still carry the risk.
Negative timestamps are valid — they represent dates before 1970 (e.g. -86400 = 1969-12-31). Some parsers reject them; that is their limitation, not the format's.
Leap seconds are invisible: Unix time pretends every day has exactly 86,400 seconds; leap seconds are absorbed by smearing or repetition. For sub-second-critical work (astronomy, GPS), Unix time is the wrong tool.
JavaScript's Date parses 'YYYY-MM-DD' as UTC midnight but 'YYYY/MM/DD' as local midnight — a notorious source of off-by-one-day bugs.
0 is a valid timestamp (the epoch itself), not 'empty' — beware code that treats it as falsy.

Common errors and how to fix them

Converted date is in 1970

Cause: Seconds were interpreted as milliseconds (or the value was divided by 1000 twice).

Fix: Multiply by 1000 exactly once when passing seconds to millisecond APIs like JavaScript's new Date(ms).

Date shows the year 58,000+ or 'Invalid Date'

Cause: Milliseconds fed into a seconds API, or microseconds/nanoseconds fed anywhere unaware.

Fix: Count digits: 13 → divide by 1000 for seconds; 16 → by 10^6; 19 → by 10^9.

Result is off by exactly your timezone offset (e.g. 7 hours)

Cause: A date string without offset was parsed as UTC by one system and as local time by another.

Fix: Always serialize with explicit offset or Z. When pasting a bare date here, be aware of which interpretation you want (UTC vs local display).

Off by one day around midnight

Cause: Date-only values ('2026-07-08') interpreted at UTC midnight, then displayed in a zone behind UTC — or the JS YYYY-MM-DD vs YYYY/MM/DD parsing split.

Fix: For date-only data, keep it as a calendar date (no timestamp) end to end; only attach zones to actual instants.

MySQL rejects dates after 2038

Cause: The legacy TIMESTAMP column type is 32-bit.

Fix: Use DATETIME (with app-side UTC discipline) or migrate to 64-bit-safe types.

Tips and best practices

Instant digit check: 10 = seconds, 13 = ms, 16 = µs, 19 = ns. Memorize it — it solves most 'weird date' tickets on sight.
In logs and databases, prefer UTC ISO 8601 with offset (2026-07-08T07:30:00Z) for readability plus precision; timestamps for arithmetic.
Comparing JWT exp? It is seconds — JavaScript's Date.now() must be divided by 1000 before comparing.
For recurring schedules, timestamps are the wrong abstraction (they encode instants, not rules) — that is what cron expressions and RRULEs are for.
date -d @1783150200 (Linux) and date -r 1783150200 (macOS) convert in the terminal; this page saves you remembering which flag is which.

Frequently asked questions

How does the tool know if my number is seconds or milliseconds?: By magnitude: current-era timestamps have 10 digits in seconds and 13 in milliseconds, so the digit count identifies the unit. Ambiguity only exists for dates near 1970 or far future — if the result looks wrong, check the unit explicitly with the Epoch Converter tool.
What timezone is a Unix timestamp in?: None — it counts seconds since 1970-01-01T00:00:00 UTC and identifies the same instant worldwide. Timezone applies only when formatting it into a human date. Store UTC/timestamps; localize at display time.
Why do I get 'Invalid Date' for my date string?: The string doesn't match a parseable format. Safest input is ISO 8601 (2026-07-08T14:30:00Z or with ±hh:mm offset). Ambiguous formats like 03/04/2026 depend on locale (March 4 vs April 3) and are best avoided entirely.
Is the year 2038 problem still real?: For 64-bit systems, no — they are safe for ~292 billion years. It persists in embedded/IoT devices, old file formats, and MySQL's legacy TIMESTAMP column. New designs should simply avoid 32-bit second counters.
Do Unix timestamps include leap seconds?: No. Unix time defines every day as 86,400 seconds; leap seconds are smoothed over (Google/AWS smear them across the day). Consequently Unix time is about 27–37 seconds off TAI — irrelevant for business software, disqualifying for high-precision science.
Can timestamps be negative or zero?: Yes: 0 is the epoch itself and negative values are pre-1970 dates (-86400 = Dec 31, 1969). Both are valid; watch for code that treats 0 as 'no value' and parsers that refuse negatives.

Embed this tool

Add Timestamp Converter to your own site, blog post, or internal docs — free, no signup. The widget runs entirely in your visitors' browsers, same as it does here.