Which epoch converter should I use?

Use Epoch to Date when you already have a Unix timestamp and need readable time. Use Date to Epoch when you start with a calendar date or datetime and need Unix seconds or milliseconds.

Why does my converted date land in 1970?

Almost always because seconds were read as milliseconds. JavaScript's Date and Date.now() use milliseconds, so passing a 10-digit seconds value lands in January 1970. Multiply the seconds by 1000 first.

Why is my converted time off by exactly one hour?

That is a timezone or daylight-saving mistake, not a math error. The converter applied a different timezone, or the local time fell on a DST transition. Switch the converter to UTC to see the canonical instant, then apply the zone you actually want.

What is the best epoch converter format to copy?

For code, copy Unix seconds or milliseconds based on what the target API documents. For humans, copy ISO 8601 with a Z or an explicit timezone offset so the instant is unambiguous.

Does an epoch converter use UTC or local time?

The Unix timestamp itself is UTC-based. A converter can display that same instant in UTC or in a local timezone; choose UTC for debugging and a named IANA timezone for user-facing output.

Why do epoch converters show different local times?

They are applying different timezones. The underlying UTC instant is identical; only the local display changes. Switch the converter to UTC to compare the canonical value.

How do I know if my number is seconds or milliseconds?

Count the digits. A modern 10-digit value is Unix seconds; a 13-digit value is Unix milliseconds. If a 10-digit value lands near 1970 in JavaScript, it was treated as milliseconds and needs multiplying by 1000.

← All posts

Epoch Converter Guide: Choose the Right Tool and Avoid Wrong Dates

By unixepochtime.com editorial teamMay 19, 2026Updated June 29, 2026

Use an epoch converter by choosing the direction first: epoch to date when you have a number, date to epoch when you have a calendar time. Then check the unit (seconds vs milliseconds) and the display zone (UTC vs local) before copying the result.

How to choose an epoch converter without stealing the tool job

This guide is the support layer for converter searches, not the converter itself. If you need a quick conversion, use the focused tools below; if the output looks wrong, come back here to diagnose whether the problem is direction, unit, timezone, or precision.

Choose epoch to date for numeric input

If the input is a 10-digit, 13-digit, 16-digit, or 19-digit number, start with the Epoch to Time converter. The job is to turn a Unix integer into UTC, ISO 8601, and local display output.

Choose date to epoch for calendar input

If the input is a wall-clock value like 2026-01-01 00:00 in Los Angeles, start with the Date to Epoch converter. The job is to interpret a calendar time in the correct timezone and return Unix seconds or milliseconds.

Use this guide when the result looks wrong

A result near 1970, a date in the year 55,000, or a one-hour offset is almost always an input assumption problem. The sections below show the checks to run before blaming the converter.

The seven mistakes that produce a wrong date

An epoch converter does simple arithmetic, so when the output is wrong the cause is almost never the math — it is the input. A timestamp carries no label telling you whether it is seconds or milliseconds, UTC or local, or how precise it is, and every wrong conversion comes from guessing one of those wrong. The fastest tell is the resulting year: a date near 1970 or thousands of years in the future is a unit mismatch, and a date that is right but off by a round number of hours is a timezone mistake. The table below is the field guide; the sections after it explain the unit and timezone mistakes in depth and show how to verify a conversion in code.

Mistake	What you see	Cause	Fix
Seconds read as milliseconds	Date lands in 1970	JS Date and Date.now() expect ms; you passed 10-digit seconds	Multiply seconds by 1000
Milliseconds read as seconds	Date thousands of years in the future	13-digit value passed to a seconds function	Divide by 1000 first
UTC shown as local time	Right day, clock off by your offset	Converter defaulted to a different timezone	Switch the converter to UTC
Local time copied without its offset	Off by hours on another machine	A wall-clock time stored with no zone	Store UTC plus the timezone
DST-ambiguous wall time	Off by exactly one hour near a transition	A local time that occurs twice or never	Convert from UTC; pin the IANA zone
Micro/nanoseconds read as seconds	Date far in the future (16 or 19 digits)	Database or tracing value in µs or ns	Divide by 1,000,000 (µs) or 1,000,000,000 (ns)
Trusting the displayed precision	Sub-second part silently dropped	Converter truncated the milliseconds	Confirm the unit the target API documents

What an epoch converter does

An epoch converter turns numeric timestamps into readable dates and turns human dates back into epoch timestamps. A good one handles Unix seconds, Unix milliseconds, UTC output, local timezone output, and ISO 8601 strings, and it makes the unit obvious before you copy a value into code, a database, or an API request. Epoch converter, Unix time converter, Unix timestamp converter, and Unix epoch calculator all describe the same job: translate between a count of seconds (or milliseconds) since January 1, 1970 UTC and a date a human can read. The converter is rarely the problem — the input usually is.

Epoch converter is the broad workflow

The broad term can mean either direction: number to date or date to number. That is why the homepage is the right destination for head-term converter searches.

Epoch Unix time converter usually means the same thing

Unix time, epoch time, POSIX time, and epoch timestamp are common labels for the same UTC-based count. The practical question is not the label; it is which direction and unit the task needs.

Epoch timestamp converter should preserve the unit

If your source system produced milliseconds, keep milliseconds until the receiving API explicitly asks for seconds. Silent unit changes are the fastest path to 1970 and year-55,000 bugs.

The unit mistakes: seconds, milliseconds, micro, nano

The single most common conversion error is a unit mismatch, and it has a signature: the date lands in 1970, or thousands of years away. JavaScript is where it bites most often, because the Date constructor and Date.now() both work in milliseconds while most APIs, databases, and the Unix date command work in seconds. Pass a 10-digit seconds value to new Date() without multiplying by 1000 and you land 53 years too early. The reverse — feeding 13-digit milliseconds to a seconds function — throws the date far into the future. Higher-precision sources make it worse: databases often emit 16-digit microseconds and tracing systems 19-digit nanoseconds, and both look like a valid Unix value until they decode to the wrong millennium.

10 digits → seconds (e.g. 1700000000); 13 → milliseconds; 16 → microseconds; 19 → nanoseconds
JavaScript: new Date(seconds * 1000), or new Date(ms) directly
Microseconds → divide by 1,000,000 before converting; nanoseconds → divide by 1,000,000,000
Sanity check: the result should be a believable date in the current decade

Seconds vs milliseconds is the first check

Modern Unix seconds are 10 digits; modern Unix milliseconds are 13 digits. Count digits before choosing any converter option.

Microseconds and nanoseconds need explicit scaling

A 16-digit database value is usually microseconds and a 19-digit tracing value is usually nanoseconds. Divide before using a seconds- or milliseconds-based converter.

The timezone mistakes: UTC vs local and DST

Once the unit is right, the remaining errors are timezone errors, and they share a signature too: the date is correct but the clock is off by a whole number of hours. A Unix timestamp is a single instant with no timezone of its own; the offset is applied only when the instant is formatted. So two converters set to different timezones show different clock times for the same number — neither is wrong, they are just displaying different local views. The trap is copying a local wall-clock time without recording which zone it came from, or converting a time that falls on a daylight-saving transition, where a local time can occur twice or not at all. When a result is off by exactly one hour, suspect DST before you suspect the converter.

Compare values in UTC; apply a local timezone only at the moment you display them
Never store a local time without also storing its IANA zone or UTC offset
Around a DST change, derive the instant from UTC, not from an ambiguous local time

UTC is the comparison view

When two tools disagree, set both to UTC first. If the UTC output matches, the timestamp is correct and only the local display differs.

Local time belongs at display time

Store the instant as UTC or Unix time, then render it in an IANA timezone such as America/Los_Angeles or Europe/Berlin when a person needs to read it.

Choose the direction first

Most timestamp tasks are one of two directions: epoch to date, or date to epoch. Deciding the direction first prevents the most common cause of wrong test data and broken API payloads — converting the right value the wrong way.

Epoch to date: paste 1700000000 and read the UTC or local date
Date to epoch: choose 2026-01-01 00:00:00 UTC and get 1767225600
Confirm whether the target expects seconds or milliseconds before you copy the result

What to verify before copying a converted value

A converter can only be as correct as the input is unambiguous. Before copying a timestamp into a test, cron job, migration, or API request, confirm the unit, the timezone, and the expected precision. The fastest sanity check is the resulting year: a date near 1970 or far in the future almost always signals a unit mismatch rather than a converter error.

Does the receiving system expect seconds or milliseconds?
Is the displayed date UTC or local time?
Will the timestamp represent an instant or a local calendar date?
Does the database column store native datetime, Unix seconds, or Unix milliseconds?
Is the result near 1970 or far in the future, which usually signals a unit mismatch?

Verify a conversion in code

When a converted value matters — a migration, a billing boundary, a cron schedule — do not trust a single tool. Re-derive the same instant in your own runtime and check that the two agree in UTC. Each of these prints an unambiguous ISO 8601 string with a Z suffix, so there is no local-timezone guesswork to compare.

JavaScript: new Date(1700000000 * 1000).toISOString() // '2023-11-14T22:13:20.000Z'
Python: datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
Shell (GNU): date -u -d @1700000000 +'%Y-%m-%dT%H:%M:%SZ'
If the tool and your runtime disagree, the input unit or timezone is the suspect — not the converter

Worked example: one instant, three representations

Take the instant 2026-01-01 00:00:00 UTC. As Unix seconds it is 1767225600; as Unix milliseconds it is 1767225600000; as ISO 8601 it is 2026-01-01T00:00:00Z. All three describe the same moment — only the format and unit differ. The instant never carries a timezone of its own; New York would display that same value as 2025-12-31 19:00:00, because the offset is applied at display time, not stored in the number.

FAQ

Which epoch converter should I use?: Use Epoch to Date when you already have a Unix timestamp and need readable time. Use Date to Epoch when you start with a calendar date or datetime and need Unix seconds or milliseconds.
Why does my converted date land in 1970?: Almost always because seconds were read as milliseconds. JavaScript's Date and Date.now() use milliseconds, so passing a 10-digit seconds value lands in January 1970. Multiply the seconds by 1000 first.
Why is my converted time off by exactly one hour?: That is a timezone or daylight-saving mistake, not a math error. The converter applied a different timezone, or the local time fell on a DST transition. Switch the converter to UTC to see the canonical instant, then apply the zone you actually want.
What is the best epoch converter format to copy?: For code, copy Unix seconds or milliseconds based on what the target API documents. For humans, copy ISO 8601 with a Z or an explicit timezone offset so the instant is unambiguous.
Is an epoch converter the same as a Unix time converter?: For most developer searches, yes. Epoch converter, Unix time converter, Unix timestamp converter, and Unix epoch calculator all convert between Unix epoch timestamps and readable dates.
Does an epoch converter use UTC or local time?: The Unix timestamp itself is UTC-based. A converter can display that same instant in UTC or in a local timezone; choose UTC for debugging and a named IANA timezone for user-facing output.
Why do epoch converters show different local times?: They are applying different timezones. The underlying UTC instant is identical; only the local display changes. Switch the converter to UTC to compare the canonical value.
How do I know if my number is seconds or milliseconds?: Count the digits. A modern 10-digit value is Unix seconds; a 13-digit value is Unix milliseconds. If a 10-digit value lands near 1970 in JavaScript, it was treated as milliseconds and needs multiplying by 1000.