Epoch / Unix Timestamp Converter (Seconds, ms, UTC/Local)
Turn “10 vs 13 digits” into the right date instantly, verify UTC vs local time (DST included), and generate ISO-8601/RFC-3339 strings you can paste into logs, APIs, and databases.
| Epoch (seconds) | — |
| Epoch (milliseconds) | — |
| ISO-8601 (UTC) | — |
| ISO-8601 (Local) | — |
Decode epoch timestamps without guessing seconds, milliseconds, or DST
If a log line shows 1700000000 and another shows 1700000000000, the only difference is a factor of 1,000—but it changes the date by decades if you misread it. This page focuses on the failure modes engineers actually hit: seconds vs milliseconds, fractional seconds, and UTC vs Local around daylight saving time.
Last Verified: December 2025
- Epoch → Date: decode seconds, milliseconds, and decimals (fractional seconds) and show both UTC and Local renders.
- Date/Time → Epoch: compute epoch seconds and milliseconds from a chosen instant (interpreted as UTC or Local).
- String → Epoch/Date: paste an ISO/RFC string or pick an explicit D-M-Y / M/D/Y / Y-M-D format to avoid day/month swaps.
More time tools: Time & Date hub · Need offset conversions? Time Zone Converter
Quick reference: seconds vs milliseconds (and the “looks right” check)
The safest way to sanity-check is to look at both the digit count and the magnitude. “Digits” catches most cases; “magnitude” catches shortened IDs or trimmed logs.
| What you see | Likely unit | Magnitude check | Typical example | Common mistake |
|---|---|---|---|---|
| 10 digits | Seconds | ~1,500,000,000 to 2,000,000,000 for modern dates | 1700000000 | Treating as ms → date near 1970 |
| 13 digits | Milliseconds | ~1,500,000,000,000 to 2,000,000,000,000 for modern dates | 1700000000000 | Treating as s → far-future date |
| Decimal value | Seconds with fraction | Integer part behaves like seconds | 23505.396 | Assuming decimal means ms |
| Negative value | Pre-1970 | -1 s = 1969-12-31T23:59:59Z | -86400 | Forgetting “-” means before epoch |
Tip (math/logic): use the “1970 tell”
If you decode something that should be “recent” and it lands in January 1970, you almost certainly treated milliseconds as seconds or vice versa (a ×1000 / ÷1000 error).
UTC vs Local: why the same instant shows two different clock times
An epoch number represents one instant in time. The difference between “UTC” and “Local” is just how that instant is rendered as a wall-clock time (with an offset like +01:00 or +02:00).
- UTC output is stable and avoids DST jumps. It’s the safest choice for APIs, logs, and databases.
- Local output matches what a person saw on their device in their time zone (including DST rules).
Common pitfall (math/logic): converting a local time that never existed
During a spring DST change, some local times are skipped (for example, 02:30 may not exist). In autumn, some local times occur twice. If you must store “local clock time,” also store the time-zone offset or use UTC to keep it unambiguous.
Working with durations between dates? Date Duration Calculator · Checking birthdays/age cutoffs? Age Calculator
Input handling rules (what gets parsed, and how)
Epoch → Date
- Auto units: 10 digits → seconds; 13 digits → milliseconds. If there’s a decimal, it’s treated as seconds with a fractional part.
- Fractional seconds: 23505.396 seconds becomes 23505396 milliseconds (seconds × 1000).
- Short-epoch time-only: if enabled, 5-digit seconds or 8-digit milliseconds render as time-of-day without a date (useful for “seconds since midnight” style values).
Date/Time → Epoch
- Interpret as Local: the selected date/time is treated as your browser time zone (DST-aware), then converted to UTC epoch.
- Interpret as UTC: the selected fields are treated as UTC directly (no local offset applied).
String → Epoch/Date
- Auto: ISO-8601 and RFC-2822 typically parse cleanly.
- Ambiguous numeric dates: pick D-M-Y vs M/D/Y vs Y-M-D explicitly to prevent day/month swaps.
Examples with real numbers (and what to conclude)
Example 1: “seconds vs milliseconds” in one glance
- 1700000000 (seconds) and 1700000000000 (milliseconds) represent the same scale of modern dates—just different units.
- If you decode 1700000000000 as seconds, you’ll land far in the future. That’s the ×1000 mistake.
Example 2: fractional seconds
23505.396 means 23,505 seconds plus 396 milliseconds. Converting by hand: 23505.396 × 1000 = 23505396 ms. If your system expects milliseconds, this is the correct normalization.
Example 3: before 1970
-1 seconds is exactly one second before the epoch start: 1969-12-31T23:59:59Z. Negative epochs are valid and common in historical datasets.
FAQ
What is Unix epoch time?
Unix epoch time is the count of seconds (or milliseconds) since 1970-01-01T00:00:00Z. It ignores leap seconds.
How do I tell seconds vs milliseconds?
Most systems use 10 digits for seconds and 13 digits for milliseconds. Values around 1.7e9 are seconds; around 1.7e12 are milliseconds.
Do you support fractional seconds like 23505.396?
Yes. In Auto units, a decimal is treated as seconds with a fractional part, so 23505.396 seconds becomes 23505396 milliseconds.
Why show both UTC and Local?
UTC avoids daylight saving time shifts; Local shows what a user saw on the clock. The same instant can differ by the time-zone offset.
Can I convert dates before 1970?
Yes. Pre-1970 instants are negative epoch values (for example -1 seconds is 1969-12-31T23:59:59Z).
What is the time-only display for short epochs?
When enabled, 5-digit seconds or 8-digit milliseconds are interpreted as time-of-day only and rendered without a calendar date.
Which date string formats are supported?
Auto parses ISO-8601 and RFC-2822. For ambiguous numeric dates, select D-M-Y, M/D/Y, or Y-M-D to control the day/month order.
Does an epoch timestamp include a time zone?
No. An epoch number represents a single moment in UTC; time zones only affect how that moment is displayed.
What happens during DST changes?
Some local times are skipped or repeated during DST transitions. Converting via UTC is the safest way to avoid ambiguity.
Is there a maximum or minimum supported date?
Browsers have a finite Date range; extremely large epoch magnitudes may be out of range and should be treated as errors.
Assumptions, limits, and a short disclaimer
- Leap seconds: epoch time ignores leap seconds (common industry behavior).
- Parsing ambiguity: numeric dates like 01/02/2025 require an explicit format choice to avoid day/month inversion.
- DST behavior: Local times can repeat or be skipped; UTC is the unambiguous reference.
- Range: extremely large timestamps may exceed browser Date limits and should be handled as errors.
Disclaimer: Educational utility only. No guarantees; verify against your system’s logging and time-zone rules for production decisions.