Epoch & Timestamp Converter

Q: How do I tell whether a timestamp is in seconds or milliseconds?

By its size. A seconds timestamp for any date near today is about 1.7 billion — ten digits. The same instant in milliseconds is about 1.7 trillion — thirteen digits. Microseconds add three more digits, nanoseconds another three. This tool applies that test automatically and tells you which band your number fell into, but it also tells you when a value is too small to be sure, rather than guessing confidently and being wrong.

Q: What is the Unix epoch?

Midnight UTC on 1 January 1970, the zero point that Unix time counts from. A timestamp is simply the number of seconds elapsed since then, which makes it timezone-free, easy to compare and easy to store. Dates before 1970 are represented as negative numbers, which some languages and databases handle poorly — worth knowing if you work with historical data.

Q: What is the Year 2038 problem?

Systems that store Unix time in a signed 32-bit integer can only count to 2,147,483,647 seconds, which runs out at 03:14:07 UTC on 19 January 2038. One second later the counter overflows to a large negative number and the date reads as December 1901. It is not only a future problem: anything calculating an expiry, a mortgage term or a certificate validity more than a decade ahead is already producing values past the limit. This tool flags any timestamp beyond it.

Q: Why does my timestamp show a different date than I expected?

Almost always timezone or unit. If the date is right but the day is off by one, you are probably looking at a midnight-UTC value from a timezone behind Greenwich — the instant is correct, the calendar day differs. If the year is wildly wrong, it is a unit mismatch: 1970 means milliseconds were read as seconds, and a year in the tens of thousands means the reverse.

Q: Should I store dates as timestamps or as strings?

Store the instant, not the rendering. A timestamp or a UTC datetime column is unambiguous, sorts correctly and compares cheaply. If you need to know the wall-clock time somewhere specific — a 9am appointment in Berlin — store the IANA zone name alongside it, never a fixed offset, because the offset changes twice a year while the zone name does not.

Q: Does this handle daylight saving correctly?

Yes, using your browser's own IANA timezone database, and the table marks which zones are currently in DST. That detection compares each zone's offset at the given instant against its own January and July offsets, so it works in the southern hemisphere too — where a naive 'summer means DST' rule gets Sydney and Auckland backwards for half the year.

Convert Unix timestamps to dates in any timezone, with the seconds-or-milliseconds question answered for you.

Timestamp or date

Paste a bare epoch number in any unit, or a date string like 2026-01-01T00:00:00Z. The unit is worked out from the magnitude — override it above if the guess is wrong.

Epoch values

Seconds

Milliseconds

Microseconds

Nanoseconds

Formatted

ISO 8601 (UTC)

ISO 8601 (your offset)

RFC 1123 / HTTP date

Your local format

Around the world — you are in

Zone	Local time	Offset

What It Does

This tool converts between Unix timestamps and human dates, and its real job is the part nobody else does properly: working out what unit your number is in. A bare epoch value can be seconds, milliseconds, microseconds or nanoseconds depending on which system produced it, and picking the wrong one silently gives you a date in 1970 or in the year 55000. The unit is inferred from the magnitude, stated openly, and can be overridden. Everything then follows — every unit, every common format, and the same instant in as many timezones as you want.

When to Use It

A log line has a bare epoch number and you need to know when it actually happened.
An API returned a timestamp that renders as 1970, and you need to confirm whether it is seconds or milliseconds.
You are coordinating a release or an incident across timezones and need one instant expressed in all of them.
You are writing a test fixture and need a stable epoch value for a specific date.

Worked Examples

1767225600

Ten digits, so it is read as seconds. Note that it is exactly midnight UTC — the analysis calls that out, because a date-only value compared against a full timestamp is where off-by-one-day bugs start.

1767225600000

The same instant in milliseconds. Thirteen digits puts it firmly in the milliseconds band, which is what JavaScript's Date.now() and most JVM APIs produce.

2147483648

One second past the 32-bit signed limit. This is the Year 2038 problem: any system still storing time in a 32-bit time_t wraps this to December 1901.

1000

Genuinely ambiguous, and the analysis says so rather than guessing confidently. It could be a real timestamp seventeen minutes into 1970, or a value in another unit — only you know which.

Common Mistakes

Assuming every timestamp is in seconds. Unix time is defined in seconds, but JavaScript, Java and many APIs work in milliseconds, and Go, Rust and databases often use microseconds or nanoseconds. A millisecond value read as seconds lands in the year 57000; a seconds value read as milliseconds lands in January 1970.
Comparing a date-only value against a full timestamp. A date stored as midnight UTC is a specific instant, and in any timezone west of Greenwich that instant falls on the previous calendar day. This is the single most common cause of reports being off by one day.
Storing time as a 32-bit signed integer. That counter overflows on 19 January 2038, and anything computing an expiry more than a decade out is already hitting it today. The analysis flags any value past the rollover.
Treating a timezone offset as a timezone. -05:00 is not the same thing as America/New_York, because the offset changes with daylight saving. Storing an offset instead of a zone name means future dates land an hour out for half the year.
Assuming local time is unambiguous. During a daylight-saving fall-back, one local hour happens twice; during spring-forward, another never happens at all. Store and transmit UTC, and convert to local only for display.

Features

Detects seconds

milliseconds

microseconds and nanoseconds from magnitude

Manual unit override when the guess is wrong

Every unit shown at once

ISO 8601 in UTC and in your own offset

HTTP date and local formats

Any number of timezones side by side with live DST flags

Relative phrasing such as 3 hours ago

Year 2038 rollover warning

Midnight-UTC date detection

Runs entirely in your browser

How to Use

1. Paste an epoch number or a date string — the box starts on the current time. 2. Check the detected unit in the analysis; override it in the dropdown if the guess is wrong. 3. Read the converted values, or copy any of them with the button beside it. 4. Add timezones from the dropdown to see the same instant everywhere you need it.

Frequently Asked Questions

How do I tell whether a timestamp is in seconds or milliseconds?

What is the Unix epoch?

What is the Year 2038 problem?

Why does my timestamp show a different date than I expected?

Should I store dates as timestamps or as strings?

Does this handle daylight saving correctly?

Embed this Epoch & Timestamp Converter

Paste this snippet into your site to embed the tool.

<iframe src="https://webtoolworld.com/embed/timestamp-converter" style="width:100%;min-height:560px;border:0" loading="lazy" title="Epoch &amp; Timestamp Converter"></iframe>
<p style="font-size:12px;margin-top:6px"><a href="https://webtoolworld.com/timestamp-converter">Epoch &amp; Timestamp Converter</a> by WebToolWorld</p>

Everything runs in your browser — nothing you enter is uploaded or stored. Timezone conversion and daylight-saving rules come from your browser's own IANA database, so results reflect whatever version of the timezone data your browser ships. Historical dates before about 1970, and dates far in the future, may differ from other tools because timezone rules change and past rules are recorded inconsistently. Unit detection is a magnitude heuristic, not a guarantee: it is stated openly and can always be overridden.