Learn how to convert from epoch (Unix time) to readable dates with zero confusion. Step-by-step guides, examples, pitfalls, and expert tips—optimized for speed and accuracy with ZenixTools.
Introduction
Epoch time (also called Unix time or POSIX time) is everywhere—APIs, logs, databases, IoT, and finance. When you need to convert from epoch to a human-readable date, accuracy matters. This guide shows you the fastest, safest ways to convert timestamps, avoid common mistakes, and standardize time across systems using ZenixTools and popular languages.
Featured Snippet: Quick Answer
To convert from epoch to a human-readable date, first detect units: 10 digits = seconds; 13 digits = milliseconds. Convert to UTC, then format to your time zone if needed. Example: JavaScript new Date(1704067200 * 1000).toISOString(). On Linux: date -u -d @1704067200. In Python: datetime.utcfromtimestamp(1704067200). Use ZenixTools for instant conversions and bulk lists.
Key Takeaways
AI Overview (Concise Summary)
This guide explains how to convert from epoch (Unix time) into readable dates safely and quickly. Learn the difference between seconds and milliseconds, how to handle UTC vs local time, and avoid DST pitfalls. It provides step-by-step methods using ZenixTools, Linux date, JavaScript, Python, SQL, Excel, and more. You’ll find real examples, best practices, expert tips, a comparison table, and 15 FAQs to cover every common scenario.
Table of Contents
“Convert from epoch” means turning a Unix timestamp—the count of seconds (or milliseconds) since 1970-01-01T00:00:00Z (UTC)—into a readable date and time like 2024-01-01 00:00:00 UTC or your local time zone.
Key points:
Follow these steps to convert from epoch accurately in any environment.
Tip: If you’re unsure about units, toggle “Detect ms vs s”. ZenixTools checks length and realistic ranges.
date -u -d @1704067200
date -d @1704067200
ms=1704067200000; date -u -d @$(echo "$ms/1000" | bc)
Note: GNU date supports -d. On BSD/macOS, use:
date -u -r 1704067200
const ts = 1704067200; // seconds
const d = new Date(ts * 1000);
console.log(d.toISOString()); // 2024-01-01T00:00:00.000Z
const ms = 1704067200000;
console.log(new Date(ms).toLocaleString('en-US', { timeZone: 'America/New_York' }));
new Intl.DateTimeFormat('en-GB', {
timeZone: 'UTC',
year: 'numeric', month: '2-digit', day: '2-digit',
hour: '2-digit', minute: '2-digit', second: '2-digit',
hour12: false
}).format(new Date(1704067200 * 1000));
from datetime import datetime, timezone
sec = 1704067200
print(datetime.fromtimestamp(sec, tz=timezone.utc).isoformat())
from datetime import datetime
ms = 1704067200000
print(datetime.fromtimestamp(ms/1000.0))
from datetime import datetime
from zoneinfo import ZoneInfo
sec = 1704067200
ny = datetime.fromtimestamp(sec, tz=ZoneInfo('America/New_York'))
print(ny.isoformat())
long sec = 1704067200L;
Instant instant = Instant.ofEpochSecond(sec);
ZonedDateTime utc = instant.atZone(ZoneOffset.UTC);
ZonedDateTime ny = instant.atZone(ZoneId.of("America/New_York"));
System.out.println(utc); // 2024-01-01T00:00Z
System.out.println(ny);
For milliseconds:
Instant instant = Instant.ofEpochMilli(1704067200000L);
$sec = 1704067200;
echo gmdate('c', $sec); // ISO 8601 UTC
$dt = new DateTime('@'.$sec); // UTC
$dt->setTimezone(new DateTimeZone('America/New_York'));
echo $dt->format('Y-m-d H:i:sP');
ts := int64(1704067200)
utc := time.Unix(ts, 0).UTC()
fmt.Println(utc.Format(time.RFC3339))
SELECT to_timestamp(1704067200) AT TIME ZONE 'UTC';
SELECT (to_timestamp(1704067200) AT TIME ZONE 'America/New_York');
SELECT FROM_UNIXTIME(1704067200); -- local server time
SELECT CONVERT_TZ(FROM_UNIXTIME(1704067200), 'UTC', 'America/New_York');
SELECT datetime(1704067200, 'unixepoch'); -- UTC
SELECT datetime(1704067200, 'unixepoch', 'localtime'); -- local
=A2/86400 + DATE(1970,1,1)
=A2/86400000 + DATE(1970,1,1)
Format the cell as Date/Time. Adjust for your time zone with TIME or custom offsets, or use built-in time zone functions in Apps Script.
Note: Excel’s 1900 date system contains a known “1900 leap year” quirk. For epoch conversions, the formulas above work correctly.
echo 1704067200000 | jq -R 'tonumber/1000 | todate'
awk 'BEGIN { print strftime("%Y-%m-%dT%H:%M:%SZ", 1704067200) }'
Debugging an API:
Log correlation across services:
Financial events:
IoT sensor data:
Database migration:
Confusing seconds and milliseconds
Mixing UTC and local time
Ignoring DST effects on display
Hardcoding time zone abbreviations
32-bit time_t and Y2038
Inconsistent offset math
Excel parsing surprises
Losing precision
Note: Leap seconds are usually ignored by Unix time. Do not expect 23:59:60 to appear in standard conversions.
| Method | Best For | Time Zone Support | Milliseconds | Pros | Cons |
|---|---|---|---|---|---|
| ZenixTools | One-off and bulk conversions | Yes (IANA) | Yes | Fast, zero-setup, bulk export | Requires browser |
| Linux date | CLI quick checks | Yes | Indirect (divide) | Built-in, scriptable | Syntax differs on BSD/macOS |
| JavaScript | Web apps, Node | Yes (Intl) | Yes | Ubiquitous, good formatting | Time zone DB via Intl only |
| Python | Data/ETL | Yes (zoneinfo/pytz) | Yes | Rich datetime tooling | Zone DB needed for tz |
| PostgreSQL | In-DB analytics | Yes | Seconds | Powerful time ops | Milliseconds need care |
It means turning Unix time (seconds or milliseconds since 1970-01-01T00:00:00Z) into a readable date/time like 2024-01-01 00:00:00.
Convert to a UTC datetime, then format using your desired time zone (e.g., America/New_York). Tools like ZenixTools handle this automatically.
Both exist. Many backends use seconds (10 digits), while browsers and some APIs use milliseconds (13 digits).
Check length and range. 13 digits or values greater than 10^11 usually mean milliseconds. You can also try dividing by 1000 and see if the date looks plausible.
Use A2/86400 + DATE(1970,1,1) for seconds, or A2/86400000 + DATE(1970,1,1) for milliseconds. Then format the cell as date/time.
You likely mixed UTC and local time. Convert in UTC first, then display in the correct time zone.
PostgreSQL: to_timestamp(1704067200). MySQL: FROM_UNIXTIME(1704067200). Adjust with time zone functions as needed.
Epoch is UTC and not affected by DST internally. DST only affects how you display the time in a local time zone.
Most Unix systems ignore leap seconds. Standard conversions won’t show 23:59:60.
Only on legacy 32-bit systems using 32-bit time_t. Use 64-bit time and modern runtimes to avoid this.
Parse the date in UTC, then get epoch seconds or milliseconds. All major languages provide a function for this.
Yes. ZenixTools supports bulk input and CSV/JSON export. You can also script with Python or bash.
Linux: date +%s. JavaScript: Date.now() for ms. Python: time.time() for seconds.
No. ISO 8601 is a formatted string; epoch is a numeric count. They represent the same moment and are convertible.
Check numeric type, digits (10 or 13), and reasonable ranges. Reject strings with letters or impossible values.
Conclusion
Converting epoch time should be simple, predictable, and accurate. Always detect units (seconds vs milliseconds), convert using UTC, and format for your user’s time zone. Use standards like ISO 8601/RFC 3339, and rely on tested tools and libraries. For one-off or bulk work, ZenixTools makes it effortless to convert from epoch without mistakes.
Call To Action
Ready to eliminate time bugs? Open ZenixTools, paste your timestamps, pick a time zone, and click Convert. Get instant, accurate results—and export them in the format your team needs.
Learn how to convert 1 meter to feet with precise formulas, quick methods, and real-world examples. Includes best practices, common mistakes, comparison tables, FAQs, and expert tips for accurate length conversions.
Learn how to convert 1 meter to feet with the exact formula, step-by-step instructions, quick mental math, and real-world examples. Includes charts, best practices, FAQs, and expert tips.
| MySQL |
| App backends |
| Yes |
| Seconds |
| Simple functions |
| Server tz defaults vary |
| Excel/Sheets | Business users | Limited | Yes | Familiar UI | Time zone quirks, locale issues |