Epoch Time Converter

Epoch Time Conversion

{{ epochSec }} s

{{ selectedZoneDisplay.iso || isoString }}

Epoch timestamp:

Enter seconds like 1719838800 or milliseconds like 1719838800000; use Now for the current instant.

Date and time:

Use YYYY-MM-DDTHH:MM from the picker; seconds and milliseconds derive from the resolved timestamp.

Time zone:

Choose device local, UTC, fixed UTC offset, or a browser-supported IANA zone.

UTC offset:

Enter +HH:MM or -HH:MM, such as +05:30 or -08:00.

UTC

Find named zone:

Type part of a region or city, for example Europe, Kuala_Lumpur, or America/New_.

Named zone:

Select one zone from the filtered list; availability depends on the browser environment.

Zone table filter:

Type part of an IANA name to narrow comparison rows, such as Asia or London.

Field	Value	Copy
{{ r.label }}	`{{ r.value }}` {{ r.value }}

Part (UTC)	Value	Copy
{{ p.label }}	{{ p.value }}
—

Zone	Datetime	Copy
{{ z.label }}	{{ z.value }}
No matches.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Logs, APIs, databases, build systems, and telemetry feeds often record time as a number rather than as a written date. That number is useful because it is compact, sortable, and not tied to a person's locale. It becomes risky when the unit or time zone is assumed instead of checked.

Unix time counts away from the Unix epoch, the instant at 1970-01-01 00:00:00 UTC. Positive values are after that reference point and negative values are before it. The count itself names one instant; calendar labels such as Monday, 9:00 AM, or 2024-07-01 depend on the zone rules used to display that instant.

Three ideas matter before any epoch conversion is trusted.

Epoch timestamp: A numeric count from the 1970 UTC reference instant, usually in seconds or milliseconds.
UTC instant: The zone-neutral moment that other date and time views are derived from.
Wall-clock time: A human date and time, such as 2024-07-01 09:00, that needs a zone rule before it can identify one instant.
Zone rule: Either a fixed numeric offset from UTC or a named time zone with daylight-saving and historical changes.

Epoch seconds, milliseconds, and zoned wall-clock input resolving to one UTC instant and readable calendar output

Unit mistakes are the most common failure. A 13-digit value usually represents milliseconds, while a 10-digit value near the current era usually represents seconds. Reading milliseconds as seconds can push a date tens of thousands of years into the future; reading seconds as milliseconds pulls a modern event back toward January 1970.

Time zones create a different kind of surprise. The timestamp 1704067200 is 2024-01-01 at midnight in UTC, but it is still 2023-12-31 in New York. The timestamp is not wrong; the same instant is being named with a different local calendar.

Fixed offsets are useful when a record explicitly says +05:30 or -08:00. Named time zones are better for places because they know that New York can be -05:00 in winter and -04:00 in summer. Epoch conversion is therefore not only number formatting. It is a check that the numeric count, the civil-time view, and the zone assumption all describe the same real moment.

How to Use This Tool:

Start from the value you trust most, then use the output tabs to confirm that the unit and time-zone rule match the record you are converting.

Use Epoch timestamp for a numeric machine value. Enter the number, choose seconds or milliseconds, or press Now to fill the current instant in the selected unit.
Use Date and time for a human wall-clock value. The picker supplies minute-level input, and the selected Time zone decides which UTC instant that wall-clock value means.
Choose Device local, UTC, Custom offset, or Named time zone. Use UTC for server records that are already UTC, and use Named time zone when a real region and daylight-saving rules matter.
For Custom offset, enter the offset as +HH:MM or -HH:MM. A value such as +5:30 normalizes to +05:30; invalid shapes such as UTC+5:30 or 0530 fall back to +00:00.
For Named time zone, filter with Find named zone and select the region from the list. If the expected region is missing, use a supported zone with the same civil-time rule or switch to a fixed offset when the original record gives only an offset.
Read Key Formats first. Compare Epoch (s), Epoch (ms), ISO 8601 (UTC), and Selected zone ISO before copying a value into another system.
Open UTC Date Parts, Zone Time Ledger, Selected Day Timeline, UTC Year Progress, or JSON when you need calendar parts, regional comparison rows, four selected-day checkpoints, the UTC year position, or a structured handoff.

Interpreting Results:

Treat ISO 8601 (UTC) as the neutral anchor and Selected zone ISO as the civil-time view. Different calendar dates usually mean the instant crossed midnight in the selected zone, not that the conversion failed.

Epoch (s) and Epoch (ms) are the safest handoff values when another system expects a Unix timestamp. Verify the unit before copying.
Epoch (µs) and Epoch (ns) are scaled from the millisecond instant. They do not prove the source measured microsecond or nanosecond precision.
Zone Time Ledger helps reveal a wrong-region assumption because the same instant is rendered across supported named zones.
UTC Year Progress uses the UTC day of year, so a selected-zone date near midnight can appear to belong to a different local day.

A plausible date can still be wrong when the timestamp unit or zone rule is wrong. Before saving or sharing a conversion, check the original unit, Time zone mode, and the offset suffix on Selected zone ISO.

Technical Details:

Epoch conversion reduces each accepted input path to a UTC millisecond count. From that count, calendar outputs can be rendered in UTC, shifted by a fixed offset, or formatted through a named zone. The numeric timestamp remains the same instant even when the selected-zone date, weekday, or offset changes.

Unix-style time and ECMAScript date values model civil days as regular millisecond counts and do not represent leap seconds as separate displayable instants. That makes ordinary log and API conversion predictable, but it also means a leap-second label such as 23:59:60 is outside the supported display model.

Formula Core:

The core arithmetic is simple, but it is worth making explicit because seconds, milliseconds, whole-second flooring, Julian Day values, and year progress all depend on the same UTC millisecond count.

\begin{array}{lcl} t_{ms} & = & e_{s} \times 1000 \\ e_{s} & = & ⌊ \frac{t_{ms}}{1000} ⌋ \\ JD & = & \frac{t_{ms}}{86400000} + 2440587.5 \\ MJD & = & JD - 2400000.5 \\ p_{year} & = & \frac{d_{utc}}{D_{year}} \times 100 \end{array}

Here t_ms is the UTC millisecond count, e_s is epoch seconds, JD is Julian Day, MJD is Modified Julian Day, d_utc is the UTC day of year, and D_year is 365 or 366. For example, 1704067200 seconds becomes 1704067200000 milliseconds, ISO 8601 (UTC) becomes 2024-01-01T00:00:00.000Z, and the Julian Day row becomes 2460310.50000.

Input modes and conversion rules
Input path	Conversion rule	Important boundary
Epoch seconds	Multiply the entered count by 1000 to get UTC milliseconds.	Whole-second output is floored, which matters before 1970.
Epoch milliseconds	Use the entered count as UTC milliseconds.	Microsecond and nanosecond rows scale the millisecond value; they do not add precision.
UTC datetime	Read the wall-clock fields as UTC year, month, day, hour, and minute.	No local or daylight-saving rule is applied.
Fixed offset datetime	Convert the typed offset to milliseconds and subtract it from the wall-clock value.	The offset is numeric only and has no summer or historical changes.
Named time zone datetime	Apply the selected zone's offset for the date being converted.	Rule availability and freshness depend on the browser's named-zone data.

Offset signs follow timestamp convention. A local time of 2024-07-01T09:00 at -04:00 means UTC is four hours later, so the instant is 2024-07-01T13:00:00.000Z. At +05:30, UTC is five hours and thirty minutes earlier.

UTC date parts use the UTC instant, not the selected-zone calendar. Day of year is counted from January 1 UTC with January 1 as day 1. ISO week follows the Thursday-based rule, so late December can fall in week 1 of the next ISO week-year and early January can still belong to the previous ISO week-year.

Displayed outputs and what they mean
Output	Meaning	Use with care when
Selected zone ISO	Calendar date and time in the selected zone, including the offset suffix.	The event is near midnight or a daylight-saving change.
RFC 2822 (UTC)	A UTC email-style date string for systems that expect that legacy format.	The receiving system expects local time instead of UTC.
Julian Day and Modified Julian Day	Continuous day counts derived from the UTC millisecond instant.	Another source rounds to a different number of decimal places.
Selected Day Timeline	Four samples at 00:00, 06:00, 12:00, and 18:00 in the selected zone's day.	You need a full hourly schedule or a daylight-saving transition audit.
UTC Year Progress	The UTC ordinal day divided by the number of days in that UTC year.	You need exact elapsed-year percentage by hour, minute, and second.

Custom offsets are normalized to the ±HH:MM form. Hours above 23 are capped at 23, minutes above 59 are capped at 59, and non-matching text falls back to +00:00. Named-zone conversion is only as complete as the named zones exposed by the browser environment.

Accuracy Notes:

Epoch conversion is deterministic once the unit and zone rule are known, but several limits can still change how the result should be used.

The Date and time field captures minutes, so second and millisecond precision usually comes from the timestamp path rather than from typed wall-clock input.
Named time-zone results depend on browser-supported zone data. A fixed offset is safer when the original record explicitly stores only an offset.
Leap seconds are not represented as separate 23:59:60 display values.
Very large, very old, or fractional timestamp values can expose differences between systems that store timestamps with different ranges or rounding rules.

Worked Examples:

A deployment log contains 1704067200. Enter it as Epoch timestamp in seconds and choose America/New_York as a named zone. ISO 8601 (UTC) is 2024-01-01T00:00:00.000Z, while Selected zone ISO is 2023-12-31T19:00:00.000-05:00. The local date is the previous day because New York is five hours behind UTC at that instant.

A browser timestamp arrives as 1704067200000. Choose milliseconds. Epoch (s) resolves to 1704067200, ISO Date (UTC) is 2024-01-01, and UTC Year Progress starts on day 1 of a 366-day year because 2024 is a leap year.

A meeting record says 2024-07-01T09:00 in New York. Enter that value in Date and time and choose America/New_York. The summer offset produces ISO 8601 (UTC) as 2024-07-01T13:00:00.000Z. If you use fixed offset -05:00, the UTC result shifts one hour later because the fixed offset ignores daylight-saving time.

A boundary check starts with -1 as epoch milliseconds. ISO 8601 (UTC) becomes 1969-12-31T23:59:59.999Z, and Epoch (s) becomes -1. The whole-second value is floored, so it moves to the previous second instead of rounding toward zero.

A troubleshooting case starts with a custom offset typed as UTC+5:30. The field accepts ±HH:MM, so that text falls back to +00:00. Change it to +05:30, then recheck Selected zone ISO and the offset suffix.

FAQ:

Should I choose seconds or milliseconds?

Use seconds for many Unix log and API values, and milliseconds for browser-style timestamps. A wildly futuristic date usually means milliseconds were read as seconds; a modern event near 1970 usually means seconds were read as milliseconds.

Why does UTC show a different date from the selected zone?

The same instant can cross midnight when displayed in another zone. Check ISO 8601 (UTC), Selected zone ISO, and the offset suffix before treating the date difference as an error.

When is a named time zone better than a fixed offset?

Use a named time zone when the place matters, especially near daylight-saving changes. Use a fixed offset when the original record explicitly provides only a numeric offset such as +05:30.

Do the microsecond and nanosecond rows add precision?

No. Epoch (µs) and Epoch (ns) are scaled from the millisecond instant. They help with format handoff, but they do not prove the original value was measured at those precisions.

Does the converter support leap-second timestamps?

No. The displayed date model uses regular UTC-based millisecond counts, so a leap-second label such as 23:59:60 is not represented as a separate output value.

Are entered timestamps sent to a lookup service?

No timestamp lookup service is needed for the conversion. The page derives the timestamp, date parts, zone display, and JSON in the browser, while normal page asset requests may still occur.

Glossary:

Unix epoch: The reference instant at 1970-01-01 00:00:00 UTC.
UTC: Coordinated Universal Time, used here as the neutral instant before zone rendering.
Wall-clock time: A human date and time that needs a zone rule before it identifies one instant.
Fixed offset: A numeric shift from UTC, such as +05:30, without daylight-saving or historical rules.
Named time zone: A region-style time-zone identifier whose offset can change by date.
ISO week: A week-numbering system where the week-year is based on the Thursday in that week.
Julian Day: A continuous day count used in astronomy and technical date calculations.

References:

ECMAScript Language Specification: Time Values and Time Range, Ecma International.
Date and Time on the Internet: Timestamps, IETF RFC 3339, July 2002.
Time Zone Database, Internet Assigned Numbers Authority.
Converting Between Julian Dates and Gregorian Calendar Dates, United States Naval Observatory.