How to Convert Epoch Time to a Human-Readable Date
Converting epoch time to a date is two steps — decode the number as a UTC instant, then format that instant in whatever timezone you need. This guide explains the mental model, how to tell seconds from milliseconds, and the UTC-vs-local decision, then points you to the per-language recipe and the instant converter.
Epoch to date is two steps
Converting an epoch timestamp to a readable date is always the same two steps: decode the number as an instant in UTC, then format that instant in whatever timezone you want to display. The number itself carries no timezone — it is a single moment — so the same value shows as a different wall-clock time (sometimes a different calendar day) depending on the zone you format it in. The table below shows one timestamp rendered in several zones; the rest of this guide covers the unit, the timezone choice, and the code.
| Timezone | Local date and time for 1700000000 |
|---|---|
| UTC (the canonical instant) | 2023-11-14 22:13:20 · ISO 2023-11-14T22:13:20Z |
| America/New_York | 2023-11-14 17:13:20 (EST) |
| Asia/Tokyo | 2023-11-15 07:13:20 (JST) |
| Australia/Sydney | 2023-11-15 09:13:20 (AEDT) |
What is epoch time?
Epoch time (also called Unix time or POSIX time) is the number of seconds that have elapsed since 00:00:00 UTC on January 1, 1970. It is the universal standard for representing moments in time in computing. Every programming language and operating system supports epoch time natively, which is what makes it the most reliable format for storing and exchanging timestamps between systems.
Step 1 — Identify seconds or milliseconds
Before converting, determine the unit. The unit is almost always readable from the digit count, and getting it wrong is the single most common cause of a wrong date.
- 10 digits (e.g. 1700000000) → seconds since the Unix epoch
- 13 digits (e.g. 1700000000000) → milliseconds since the Unix epoch
- 16 digits → microseconds; 19 digits → nanoseconds
- If in doubt, check whether the decoded year looks reasonable — a 1970 or far-future date means the unit was misread
- The converter above auto-detects the unit
Step 2 — Decode as UTC, then choose a timezone
A Unix timestamp decodes to one exact instant. Whether you display that instant in UTC or a local timezone is a presentation decision, not a property of the number. Pick UTC for anything machine-facing — logs, APIs, database storage, cross-server comparison — and convert to the user's IANA timezone only at the moment you show a date to a person. Always identify a zone by its IANA name (America/New_York), never a bare offset, so daylight saving is applied for you.
- Machine-facing (logs, APIs, storage) → display in UTC, ISO 8601 with a Z
- User-facing (deadlines, timestamps in a UI) → convert to the user's IANA timezone
- Never store a local time without its zone — store UTC plus the IANA zone name
The conversion in code
Every modern language has a one-line built-in that does both steps for you. The pattern is always the same: pass the value in the unit the function expects, and ask for UTC or a specific timezone. JavaScript and a few others are below; the companion recipe covers JavaScript, Python, PHP, Java, C#, Go, SQL, Excel, and Google Sheets in full.
- JavaScript: new Date(1700000000 * 1000).toISOString() → "2023-11-14T22:13:20.000Z"
- Python: datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat()
- Shell: date -u -d @1700000000 (GNU) / date -u -r 1700000000 (BSD, macOS)
- SQL: TO_TIMESTAMP(1700000000) (Postgres), FROM_UNIXTIME(1700000000) (MySQL)
- Rule: pass seconds where seconds are expected — only JavaScript's Date needs the × 1000
Common mistakes when converting epoch time
The most frequent errors when converting Unix timestamps:
- Forgetting to multiply seconds by 1000 in JavaScript — new Date(1700000000) gives the year 1970, not 2023
- Using JavaScript milliseconds directly as seconds in a server-side language (a 1000× error)
- Not specifying a timezone and relying on the server's local timezone, which varies between environments
- Storing timestamps as strings instead of integers, which breaks numeric comparisons and arithmetic
- Using the deprecated datetime.utcfromtimestamp() in Python — pass tz=timezone.utc to fromtimestamp() instead
Related articles
FAQ
- How do I convert epoch time to a date?
- Identify whether the value is seconds (10 digits) or milliseconds (13 digits), then convert with your language's date API — new Date(seconds * 1000) in JavaScript, datetime.fromtimestamp(seconds, tz=timezone.utc) in Python, or paste it into the converter above.
- Why does my epoch timestamp convert to 1970?
- You passed a seconds value to a function expecting milliseconds, most often JavaScript's new Date(). Multiply the 10-digit seconds value by 1000 first.
- Should I convert epoch time to UTC or local time?
- Use UTC for logs, APIs, and cross-server comparisons, and convert to the user's local timezone only for display. The epoch value itself is timezone-neutral.
- How do I get a date from a Unix timestamp in JavaScript?
- new Date(seconds * 1000) returns a Date object you can format with toISOString(), toUTCString(), or Intl.DateTimeFormat. The multiplication is required because JavaScript's Date expects milliseconds, not seconds.
- How do I get a date from a Unix timestamp in Python?
- Use datetime.fromtimestamp(seconds, tz=timezone.utc) for a timezone-aware UTC datetime. Drop the tz argument for local time, or append .isoformat() to get an ISO 8601 string.
- Does the same epoch value give a different date in different timezones?
- The instant is the same everywhere, but the wall-clock date you display depends on the timezone — and can even land on a different calendar day. 1700000000 is Nov 14 in New York but Nov 15 in Tokyo.
- How do I convert a timestamp into a date?
- Every modern language has a one-line built-in. The hardest part is identifying whether your timestamp is in seconds (10 digits) or milliseconds (13 digits) — get the unit right and the conversion itself never fails.