Pick the converter by input
An epoch converter is only useful after you know what kind of value you are holding. A number such as 1700000000 needs the Epoch to Date converter. A calendar value such as 2026-01-01 00:00 UTC needs the Date to Epoch converter. "Right now" needs the Current Unix Timestamp tool. A timezone dispute needs the Timezone Converter.
| You have | Use this tool | Copy this output |
|---|---|---|
| 1700000000 | Epoch to Date Converter | UTC date, local date, ISO string |
| 1700000000000 | Epoch to Date Converter | Date after confirming milliseconds |
| 2026-01-01 00:00 UTC | Date to Epoch Converter | Unix seconds or milliseconds |
| A value for the current instant | Live Epoch Converter | Current Unix seconds or milliseconds |
| "Why is New York different from UTC?" | Timezone Converter | Same instant in both zones |
| A wrong date in code | This guide first | Unit, timezone, or precision diagnosis |
This page is the support layer for converter searches. The tools do the actual conversion; this guide explains which tool to use, what to copy, and why a result sometimes looks wrong.
Numeric input means epoch to date
If the input is a 10-, 13-, 16-, or 19-digit number, start by detecting the unit. Then convert the epoch number to a readable UTC date. Only after UTC looks correct should you format it in a local timezone.
Calendar input means date to epoch
If the input is a date or datetime, decide the timezone before converting. "2026-01-01 00:00" is not one instant until you say UTC, America/New_York, Asia/Tokyo, or another IANA timezone.
Current time is a separate job
If you only need the current Unix timestamp, do not type a calendar date. Use the live current timestamp tool or a runtime call such as date +%s, Math.floor(Date.now() / 1000), or int(time.time()).
Quick diagnosis: why the converter output is wrong
Epoch conversion is simple arithmetic, so a wrong-looking result usually means one input assumption was wrong. The fastest clue is the shape of the output. Dates near 1970 point to seconds-vs-milliseconds. Dates thousands of years away point to milliseconds, microseconds, or nanoseconds being read as seconds. A result that is correct except for a whole number of hours points to timezone.
| Symptom | Likely cause | Fix |
|---|---|---|
| Date lands in 1970 | Seconds were read as milliseconds | Multiply the 10-digit value by 1000 for JavaScript Date |
| Date lands around year 55,000 | Milliseconds were read as seconds | Divide the 13-digit value by 1000 |
| Date is far beyond any real product date | Microseconds or nanoseconds were read as seconds | Divide by 1000000 or 1000000000 |
| Correct date, wrong hour | UTC/local timezone mismatch | Compare in UTC, then apply the intended IANA zone |
| Exactly one hour off near March or November | Daylight-saving gap or overlap | Use a timezone-aware converter and choose earlier/later |
| Test works locally but fails in CI | Runtime used the host timezone | Pin UTC or pass the timezone explicitly |
| Spreadsheet result is a huge future date | Epoch number formatted as Date | Format the result cell as Number |
| API rejects the timestamp | Wrong unit or float seconds | Send an integer in the documented unit |
What an epoch converter does
An epoch converter translates between a Unix epoch count and a human-readable date. The Unix epoch starts at 1970-01-01 00:00:00 UTC. The count is usually seconds, but modern systems also use milliseconds, microseconds, and nanoseconds.
The broad search terms overlap:
- Epoch converter: the broad workflow, either number to date or date to number.
- Unix time converter: usually the same task, with Unix seconds as the default.
- Unix timestamp converter: often used by developers debugging API payloads or logs.
- Epoch timestamp converter: often used when the input unit is unclear.
- Unix epoch calculator: often used for fixed dates such as year starts, deadlines, and test data.
The converter is rarely the source of the bug. The real decision is what the input represents and what the receiving system expects.
Epoch to date
Use epoch to date when you already have a number and need to know what date it represents. Example: 1700000000 is 2023-11-14T22:13:20Z when interpreted as Unix seconds.
Date to epoch
Use date to epoch when you start with a calendar value and need a Unix number. Example: 2026-01-01 00:00:00 UTC is 1767225600 seconds and 1767225600000 milliseconds.
Timezone comparison
Use a timezone converter when the same instant looks different in different places. Example: 1767225600 is 2026-01-01 00:00 UTC, but 2025-12-31 19:00 in New York.
Unit rules: seconds, milliseconds, microseconds, nanoseconds
Count digits before choosing a converter option. In modern dates, the digit count tells you the unit quickly enough for debugging, code review, and API triage.
| Digits | Unit | Example | Same instant in UTC |
|---|---|---|---|
| 10 | Seconds | 1700000000 | 2023-11-14T22:13:20Z |
| 13 | Milliseconds | 1700000000000 | 2023-11-14T22:13:20Z |
| 16 | Microseconds | 1700000000000000 | 2023-11-14T22:13:20Z |
| 19 | Nanoseconds | 1700000000000000000 | 2023-11-14T22:13:20Z |
Most Unix tools, Python, PHP, Go Unix(), SQL EXTRACT(EPOCH), and many APIs use seconds. JavaScript Date, Java currentTimeMillis, browser analytics, and many frontend event streams use milliseconds. Databases and tracing systems may use microseconds or nanoseconds.
- JavaScript Date: use new Date(seconds * 1000) or new Date(milliseconds).
- Python datetime.fromtimestamp(): pass seconds; divide milliseconds by 1000.
- PostgreSQL TO_TIMESTAMP(): pass seconds, often as a decimal for sub-second precision.
- BigQuery: use TIMESTAMP_SECONDS, TIMESTAMP_MILLIS, or TIMESTAMP_MICROS to avoid guessing.
Seconds vs milliseconds is the first check
If a modern value has 10 digits, treat it as seconds. If it has 13 digits, treat it as milliseconds. This catches the two most common wrong-date failures.
Higher precision needs scaling
Microsecond and nanosecond values are common in databases, observability tools, and event streams. Convert them explicitly before feeding them to a seconds- or milliseconds-based tool.
Timezone rules: UTC, local display, and DST
A Unix timestamp stores an instant, not a timezone. Timezone appears only when the instant is displayed. That is why two converters can show different local times for the same epoch number and both be correct.
Use UTC as the comparison view:
- Logs, API payloads, database migrations, and test fixtures should be checked in UTC.
- User-facing dates should be rendered in the user's IANA timezone.
- Local business cutoffs should store both the instant and the business timezone.
- Numeric offsets such as -05:00 are not enough for future scheduling, because daylight-saving rules change the offset.
Daylight saving time is where local date-to-epoch conversion gets subtle. In America/New_York, 2026-11-01 01:30 happens twice: once at 1793511000 and once at 1793514600. A converter or library must choose earlier, later, or reject the ambiguous input.
UTC is the debugging baseline
When two tools disagree, set both to UTC first. If the UTC output matches, the epoch value is correct and only the display zone differs.
Local time belongs at display time
Store a UTC instant or Unix timestamp. Render it in America/Los_Angeles, Europe/Berlin, Asia/Tokyo, or another IANA timezone only when a person needs to read it.
Which format should you copy?
Copy the format that matches the receiving system. The safest converter result is not always the most readable one.
| Destination | Best format | Why |
|---|---|---|
| JavaScript Date | Unix milliseconds | Date expects milliseconds |
| Python / PHP / shell | Unix seconds | These tools default to seconds |
| SQL filter | Native timestamp or Unix seconds | Easier to query and index deliberately |
| API request | Whatever the API documents | Public APIs differ |
| JSON log | ISO 8601 UTC or named Unix unit | Humans can inspect ISO; machines like integers |
| Test fixture | Both ISO UTC and epoch number | Makes the intended instant reviewable |
| Spreadsheet | Number cell, not Date format | Prevents Excel/Sheets display confusion |
| Documentation | ISO 8601 with Z or explicit offset | Removes local-time ambiguity |
For example, the instant 2026-01-01 00:00:00 UTC can be copied as:
- Unix seconds: 1767225600
- Unix milliseconds: 1767225600000
- ISO 8601 UTC: 2026-01-01T00:00:00Z
- New York display: 2025-12-31 19:00:00 America/New_York
- Los Angeles display: 2025-12-31 16:00:00 America/Los_Angeles
All five describe the same instant. The right one depends on where you will paste it.
Verify a conversion before it ships
When a converted value will go into a migration, billing boundary, cron schedule, integration test, or API request, verify it in at least one runtime you control. The goal is not ceremony; it is catching the wrong unit or timezone before the value becomes production data.
- JavaScript: new Date(1700000000 * 1000).toISOString()
- Python: datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
- GNU shell: date -u -d @1700000000 +'%Y-%m-%dT%H:%M:%SZ'
- PostgreSQL: SELECT TO_TIMESTAMP(1700000000) AT TIME ZONE 'UTC';
Expected UTC output for all four: 2023-11-14T22:13:20Z. If your output differs, check the unit first, then the timezone.
Common converter workflows
Different teams use epoch converters for different jobs. Naming the workflow makes the right tool obvious.
Debugging an API timestamp
Paste the API value into the Epoch to Date converter. If it is 10 digits, start with seconds. If it is 13 digits, start with milliseconds. Compare the UTC output with the API docs before changing application code.
Creating test data for a future date
Use Date to Epoch. Enter the date, choose UTC or the business timezone, and copy seconds or milliseconds according to the test target. Keep an ISO UTC comment beside the number so code reviewers can see the intended instant.
Checking a log event
Convert the epoch value to UTC first. Then render the same instant in the incident timezone if the on-call timeline uses local time. Do not compare local strings from different machines.
Fixing a spreadsheet import
If a timestamp appears as a far-future spreadsheet date, the sheet probably formatted the raw epoch number as a date serial. Format the cell as Number, then convert with the Excel or Google Sheets formula that matches seconds or milliseconds.
Reviewing a database migration
Prefer native timestamp columns when the database supports them. If the migration stores epoch integers, write the unit into the column name, such as created_at_seconds or created_at_ms, and verify sample rows in UTC.
Pre-copy checklist
Before copying a converted value, answer these five questions:
- Am I converting number to date, date to number, or current time?
- Is the unit seconds, milliseconds, microseconds, or nanoseconds?
- Is the displayed date UTC, browser-local, or a named IANA timezone?
- Does the receiving system document the expected unit?
- Will this value be reviewed later by humans? If yes, include an ISO 8601 UTC comment or adjacent field.
This small checklist catches the errors that make converter pages look unreliable even when the math is correct.
Related articles
FAQ
- Which epoch converter should I use?
- Use Epoch to Date when your input is a Unix number such as 1700000000 or 1700000000000. Use Date to Epoch when your input is a calendar value such as 2026-01-01 00:00 UTC. Use Current Unix Timestamp when you need the value for right now. Use Timezone Converter when the same instant must be compared across zones.
- Is an epoch converter the same as a Unix time converter?
- For most developer searches, yes. Epoch converter, Unix time converter, Unix timestamp converter, epoch timestamp converter, and Unix epoch calculator usually mean converting between Unix epoch numbers and readable dates.
- How do I know if my timestamp is seconds or milliseconds?
- Count the digits first. Modern 10-digit values are Unix seconds, 13-digit values are Unix milliseconds, 16-digit values are microseconds, and 19-digit values are nanoseconds. A 10-digit value passed to JavaScript Date without multiplying by 1000 usually lands in 1970.
- Why does my converted date land in 1970?
- Almost always because Unix seconds were read as milliseconds. JavaScript Date expects milliseconds. If you pass 1700000000 directly to new Date(), it is treated as 1.7 billion milliseconds after 1970. Multiply seconds by 1000 first.
- Why does my converted date land thousands of years in the future?
- Usually because milliseconds, microseconds, or nanoseconds were read as seconds. Divide 13-digit milliseconds by 1000, 16-digit microseconds by 1000000, or 19-digit nanoseconds by 1000000000 before using a seconds-based converter.
- Does an epoch converter use UTC or local time?
- The Unix timestamp itself is UTC-based. The converter may display the same instant in UTC, your browser timezone, or a selected IANA timezone. Use UTC for debugging and data exchange; use a named timezone for user-facing display.
- Why are two epoch converters one hour apart?
- A one-hour difference is usually a timezone or daylight-saving issue, not bad epoch math. Set both tools to UTC first. If UTC matches, the underlying timestamp is correct and only the local display zone or DST rule differs.
- What format should I copy from an epoch converter?
- For code and APIs, copy Unix seconds or milliseconds according to the receiving system's docs. For humans and documentation, copy ISO 8601 with Z or an explicit offset, such as 2026-01-01T00:00:00Z.