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.

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Unix time gives one numeric label to one instant. Instead of storing a weekday, a month name, and a local clock reading that changes from place to place, many systems keep a count from the Unix epoch, which starts at 1970-01-01 00:00:00 UTC. That single count is why the same event can move cleanly between logs, APIs, databases, dashboards, and human-readable schedules.

This converter turns that count into the calendar views people actually need. You can start with epoch seconds or milliseconds, or start with a local date and time, then see UTC output, a selected-zone ISO timestamp, a UTC parts breakdown, filtered zone comparisons, a selected-day timeline, a UTC year-progress gauge, and a JSON export of the same result set.

A tool like this matters most when one timestamp has to survive several viewpoints without drifting. A deployment may be saved as 1719838800, described to a colleague as 2024-07-01 09:00 in New York, and reviewed later in UTC during an incident write-up. The instant is the same, but the calendar date, offset, and even the weekday can change when you switch views.

The page also makes it easier to avoid common mistakes. It keeps fixed offsets separate from named time zones, shows whether you entered seconds or milliseconds, exposes UTC calendar details such as ISO week and day of year, and lets you export the result as table data, document summaries, chart files, or JSON. That gives you both a quick answer and an audit trail you can carry into another system.

Technical Details

The core of the calculation is a UTC instant stored in milliseconds. If you enter epoch seconds, the tool multiplies by 1000. If you enter epoch milliseconds, it keeps that number as the base instant. From there it derives whole-second epoch output, UTC strings, selected-zone strings, weekday labels, ISO week, quarter, day of year, Julian Day, Modified Julian Day, a four-sample day timeline, and a UTC year-progress summary.

Datetime entry works differently because a wall-clock reading means nothing until you attach a zone rule. UTC mode treats the typed value as UTC immediately. Device-local mode uses the browser environment's current zone. Fixed-offset mode applies the typed ±HH:MM offset exactly as written after normalization. Named-zone mode resolves the input through the environment's supported IANA time-zone data, which is what allows summer and winter offsets to differ when civil-time rules change.

Several outputs are intentionally derived rather than independently measured. Epoch (s) is the floor of the millisecond instant divided by 1000, so negative millisecond values round down to the next more negative whole second. Epoch (µs) and Epoch (ns) are expanded integers built from the stored millisecond value, so they are useful for format conversion but do not prove sub-millisecond capture accuracy. The year-progress gauge is also day-based rather than second-based: it uses the UTC day-of-year over the total days in that UTC year.

Conversion Core

\begin{array}{lcl} t_{ms} & = & epoch \times 1000 or direct millisecond input \\ t_{s} & = & ⌊ \frac{t_{ms}}{1000} ⌋ \\ JD & = & \frac{t_{ms}}{86400000} + 2440587.5 \\ MJD & = & JD - 2400000.5 \end{array}

Input modes and how the epoch converter interprets them
Input mode	How the tool reads it	Best use
Epoch seconds	Numeric count from the Unix epoch, scaled to milliseconds for the internal instant.	Logs, APIs, database fields, JWT claims, and telemetry where the source already stores seconds.
Epoch milliseconds	Used directly as the internal instant, with whole seconds derived afterward.	JavaScript, browser events, and systems that already store millisecond timestamps.
Datetime + UTC	The typed wall-clock value is interpreted as UTC without any extra offset rule.	Operational notes or schedules that are already written in UTC.
Datetime + fixed offset	The typed wall-clock value is shifted by the normalized `±HH:MM` offset.	Protocol samples or historical notes that name only a numeric offset.
Datetime + named time zone	The wall-clock value is resolved with the selected IANA zone and its applicable civil-time rule.	Scheduling, regional handoffs, and anything that may cross daylight-saving boundaries.

Interpretation boundaries for the epoch time converter
Field or rule	What the tool does	Why it matters
`Datetime`	Accepts minute-level input only.	Seconds are generated from the resolved instant, not typed directly.
`UTC offset`	Accepts only `±HH:MM`, clamps to valid hour and minute ranges, and falls back to `+00:00` when the shape is invalid.	A malformed offset can silently become UTC-equivalent fixed-offset input.
Named zone list	Comes from the environment's supported IANA zones, filtered in the page.	The available set depends on the runtime rather than a hardcoded list.
`Selected Day Timeline`	Samples the selected-zone day at 00:00, 06:00, 12:00, and 18:00.	It is a compact orientation view, not a full hour-by-hour timeline.
`Year Progress`	Uses UTC day-of-year divided by 365 or 366.	It shows calendar position in the UTC year, not an exact percentage down to the second.
Local processing	Builds conversions, tables, charts, and JSON in the browser with no tool-specific backend request.	Your timestamp values stay in the current session instead of being sent to a converter service.

The output is best read as a precise instant converter with calendar context. It is not a scheduling system, a leap-second audit utility, or a legal-time authority. When a future zone-law change has not reached the local environment yet, named-zone results can lag until the underlying time-zone data is updated.

Everyday Use & Decision Guide

Start from the representation you trust most. If a system already produced a timestamp, enter that value first and make sure the unit is truly seconds or milliseconds. If a person gave you a wall-clock time instead, choose the time-zone mode before filling the datetime field. That single choice decides whether the tool is matching an exact regional rule set or just applying a raw numeric offset.

The fastest quality check is to compare Epoch (s), ISO 8601 (UTC), and Selected zone ISO. Those are three views of one instant. If one looks plausible but the others do not, the usual problem is the source unit or the selected zone, not the conversion math.

Use a named time zone when daylight saving time, historical rule changes, or a real city-based schedule matters.
Use a fixed offset when the source explicitly names only a numeric offset such as +05:30 or -07:00.
Use the Zones tab when you need to brief several regions from one timestamp without re-running the conversion.
Use the Parts tab when another system asks for UTC year, month, day, hour, or ISO week as separate values.
Use the JSON export when you want a structured handoff instead of copying rows one by one.

A good working habit is to treat the summary badges as a quick sense check, then trust the table rows for exact values. The badges are useful for orientation, but the stable handoff fields are the epoch rows, the UTC ISO row, and the selected-zone ISO row.

Step-by-Step Guide

Use this sequence when you want a clean result without second-guessing the output later.

Pick the source side first. Enter a numeric timestamp into Epoch if the original source is machine-generated, or use Datetime if the original source is a human-readable wall-clock value.
If you start from Epoch, confirm the unit beside the field. A millisecond value read as seconds will jump the date far into the future, while a seconds value read as milliseconds will collapse toward January 1970.
If you start from Datetime, choose Device local, UTC, Custom offset, or Named time zone before you type. For named zones, filter the list and pick the exact location you mean.
Use Now if you need the current moment as a starting point. The live header also shows the current Unix time in seconds and the matching UTC ISO timestamp.
Read Key Formats first. Confirm that the epoch rows, the UTC ISO row, and the selected-zone ISO row all describe the same moment in different notation.
Open Parts for UTC breakdown fields, Zones for cross-region comparison, Selected Day Timeline for the selected-zone day checkpoints, and Year Progress for UTC calendar placement.
If you need to move the result elsewhere, copy an individual row, export the table as CSV or DOCX, save the chart images, or use the JSON tab for a structured payload.

Interpreting Results

The most important reading rule is that the instant does not change when the notation changes. If ISO Date (UTC) says one day while Selected zone date says another, the converter is not disagreeing with itself. It is showing that the chosen zone crosses midnight relative to UTC for that instant.

Selected zone ISO is the best field for sharing a human-readable timestamp with its offset attached.
RFC 2822 (UTC) is a compatibility rendering of the UTC instant, useful when mail-style or header-style formatting matters.
Relative is only a convenience badge based on the current moment. It is good for orientation, not for archival precision.
Julian Day and Mod. Julian are alternate day-count expressions of the same instant, which can be useful when another workflow expects astronomical-style numbering.
The Zones tab helps catch wrong-region assumptions quickly because it shows the same instant rendered across many supported locations.

Before you copy a result into another system, make one final pass across the unit, the zone mode, and the selected-zone ISO string. Those three checks prevent most timestamp mistakes.

Worked Examples

One instant, two local calendar dates

Enter 1704067200 as epoch seconds and choose America/New_York as the named zone. The UTC row resolves to 2024-01-01T00:00:00.000Z, while the selected-zone ISO row resolves to 2023-12-31T19:00:00.000-05:00. The instant is unchanged, but the local date falls on the previous evening in New York.

A daylight-saving-sensitive local time

Type 2024-07-01T09:00 in Datetime and choose America/New_York. The tool resolves that local clock reading with the zone's summer rule, which produces a selected-zone offset of -04:00 and a UTC instant of 2024-07-01T13:00:00.000Z. If you had used the fixed offset -05:00 instead, you would shift the instant by an hour and describe a different real event.

A negative millisecond boundary

Enter -1 as epoch milliseconds. The UTC ISO row becomes 1969-12-31T23:59:59.999Z, while Epoch (s) becomes -1. That result looks odd at first, but it follows the floor rule used for whole seconds.

FAQ:

Should I use a fixed offset or a named time zone?

Use a fixed offset when the source gives you only a numeric difference from UTC. Use a named time zone when the place matters, especially around daylight-saving changes or historical rule changes.

Why did my custom offset fall back to +00:00?

The field accepts only the ±HH:MM shape. Entries such as +530, UTC+5:30, or 0530 do not match that form and normalize back to +00:00.

Why does the year-progress gauge not match the exact fraction of the year down to the second?

Because the gauge is based on the UTC day number inside the UTC year. It is a calendar-position summary, not a second-accurate elapsed-time meter.

Do microseconds and nanoseconds mean the original source had that precision?

No. Those rows are scaled from the internal millisecond instant. They help with format conversion, but they do not prove that the source measured time that precisely.

Does this page send my timestamps to a backend service?

No tool-specific backend is used here. The conversion, tables, charts, and JSON payload are built in the browser session.

Glossary:

Unix epoch: The reference start point at 1970-01-01 00:00:00 UTC from which Unix-style timestamps are counted.
UTC: Coordinated Universal Time, the common reference used to describe an instant independent of local clock rules.
Fixed offset: A numeric difference from UTC such as +05:30 or -07:00 with no daylight-saving rule set attached.
Named time zone: An IANA zone identifier such as America/New_York that carries civil-time history and offset changes.
Julian Day: A continuous day-count representation often used in astronomical and technical date calculations.

References:

Definitions: Epoch, The Open Group Base Specifications.
General Concepts: Seconds Since the Epoch, The Open Group Base Specifications.
Seconds Since the Epoch, The Open Group Base Specifications Rationale.
Date and Time on the Internet: Timestamps, IETF RFC 3339.
Time zone and daylight saving time data, Internet Assigned Numbers Authority.
Converting Between Julian Dates and Gregorian Calendar Dates, United States Naval Observatory Astronomical Applications.