{{ epochTimelineStage.zoneLabel }} Epoch Timestamp {{ epochTimelineStage.dateLabel }}
Enter seconds like 1719838800 or milliseconds like 1719838800000; use Now for the current instant.
Use YYYY-MM-DDTHH:MM from the picker; seconds and milliseconds derive from the resolved timestamp.
Choose device local, UTC, fixed UTC offset, or a browser-supported IANA zone.
Enter +HH:MM or -HH:MM, such as +05:30 or -08:00.
UTC
Type part of a region or city, for example Europe, Kuala_Lumpur, or America/New_.
Select one zone from the filtered list; availability depends on the browser environment.
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.
Tags: Data Format, Date Time
Date & Time Difference Calculator Calculate elapsed time between dates with timezone offsets, workday counts, business-window overlap, checkpoint schedules, and exports.
Time Calculator Calculate elapsed time, overnight spans, break deductions, and clock shifts with rounding, audit charts, ledgers, and shareable exports.
Current Time Check your current time from the browser clock, freeze one timestamp, and compare local, UTC, Unix, ISO, offset, DST, and midnight clues.
Calendar ICS Generator Create an import-ready .ics event file with escaped calendar text, timezone modes, reminders, validation checks, JSON, and downloads.
Customize
Advanced
:

Machine timestamps are compact because they avoid month names, local clock wording, and regional formatting. A log line can sort millions of events by a single number, an API can pass one value between services, and a database can compare times without asking whether the viewer writes dates as month-day-year or day-month-year. The same compactness creates the common failure: the number looks precise even when the unit or time zone has been guessed.

The Unix epoch is the reference instant at 1970-01-01 00:00:00 UTC. Unix-style timestamps usually count seconds from that point, while browser and many application timestamps often count milliseconds. Both forms describe an instant, not a local appointment. A calendar label is added later by choosing UTC, a fixed offset, a device zone, or a named regional time zone.

Epoch seconds
A whole-second count from the 1970 UTC reference instant, common in Unix logs and server records.
Epoch milliseconds
A millisecond count for the same timeline, common in browser timestamps and many application payloads.
UTC instant
The neutral moment before any local date, weekday, offset, or regional display rule is applied.
Wall-clock time
A human date and time that needs a zone rule before it identifies a single instant.
Epoch seconds and milliseconds resolving to one UTC instant before a selected-zone date and offset are shown

Digit count is a useful clue, not proof. Around the current era, epoch seconds are commonly 10 digits and milliseconds are commonly 13 digits. Reading 1719838800000 as seconds would point far beyond normal timestamp ranges, while reading 1719838800 as milliseconds would move a 2024 event back toward January 1970.

Time-zone wording creates a separate mistake. A timestamp can be midnight in UTC and the previous evening in New York, or morning in Kuala Lumpur and the previous night in London. A fixed offset such as +05:30 is a numeric shift only. A named zone such as America/New_York carries daylight-saving and historical rules that can change the offset by date.

Epoch conversion can confirm that a numeric count, a readable date, and a zone assumption describe the same moment. It cannot prove that the source system recorded the right event, used the right clock, or preserved sub-millisecond precision. Those checks still belong in the log, database, or service that produced the timestamp.

How to Use This Tool:

Begin with the value you trust most: a numeric timestamp or a wall-clock date. Then confirm the unit and zone before copying any result into another system.

  1. Enter a number in Epoch timestamp when the source is a machine value. Choose seconds or milliseconds, or press Now to fill the current instant in the selected unit.
  2. Enter Date and time when the source is a human wall-clock value. The picker accepts minute-level input, and the selected Time zone decides which UTC instant that date and time means.
  3. Choose Device local, UTC, Custom offset, or Named time zone. Use UTC for records already stored in UTC and Named time zone when a real region and daylight-saving rules matter.
  4. For Custom offset, type +HH:MM or -HH:MM. The field normalizes a shape such as +5:30 to +05:30; text such as UTC+5:30 or 0530 falls back to +00:00.
    If the selected-zone output suddenly matches UTC, recheck the custom offset format before trusting the converted date.
  5. For Named time zone, use Find named zone and Named zone to select the region. If the expected name is unavailable, use a supported zone with the same civil-time rule or switch to a fixed offset when the source record only gives an offset.
  6. Read Key Formats first. Check Epoch (s), Epoch (ms), ISO 8601 (UTC), and Selected zone ISO together so the unit and offset suffix agree with the source.
  7. Open UTC Date Parts, Zone Time Ledger, Selected Day Timeline, UTC Year Progress, or JSON when you need calendar parts, named-zone comparisons, selected-day checkpoints, year-position checks, or a structured handoff.

Interpreting Results:

ISO 8601 (UTC) is the neutral anchor. Selected zone ISO is the same instant rendered through the chosen zone rule, including the offset suffix. A different local date usually means the instant crossed midnight in that zone, not that the timestamp changed.

  • Epoch (s) and Epoch (ms) are handoff formats. Match the receiving system's expected unit before copying.
  • Epoch (µs) and Epoch (ns) are scaled from the millisecond instant. They do not prove that the original record measured microseconds or nanoseconds.
  • Zone Time Ledger is useful when a regional assumption may be wrong because it renders the same instant across supported named zones.
  • UTC Year Progress is based on the UTC ordinal day. Near midnight, a selected-zone calendar date may belong to a different local day.

A readable date can still be a false match when seconds and milliseconds are mixed up or a region is replaced with a fixed offset. Verify the original unit, the Time zone mode, and the offset suffix before using the result in a ticket, report, or database update.

Technical Details:

Epoch arithmetic starts with a UTC millisecond count. Seconds are multiplied by 1000, millisecond inputs are used directly, and wall-clock inputs are converted to UTC by applying the selected local, UTC, fixed-offset, or named-zone rule. Once the UTC millisecond count is known, date parts, readable timestamp strings, Julian Day values, and chart checkpoints can be derived from the same instant.

JavaScript-style time values use regular millisecond counts over civil calendar fields and do not display leap seconds as a separate 23:59:60 moment. That matches ordinary logs and API timestamps, but it also means leap-second labels and source systems with different time scales need separate handling before comparison.

Formula Core:

The core formulas below use t_ms as the UTC millisecond count and e_s as epoch seconds.

tms = es×1000 es = ⌊tms1000⌋ JD = tms86400000+2440587.5 MJD = JD-2400000.5 pyear = dutcDyear×100

In the year-progress formula, d_utc is the UTC day of year and D_year is 365 or 366. For 1719838800 seconds, t_ms is 1719838800000, ISO 8601 (UTC) is 2024-07-01T13:00:00.000Z, and JD is 2460493.04167.

Input path Conversion rule Main boundary
Epoch seconds Multiply the entered value by 1000 to get UTC milliseconds. Whole-second display is floored, so negative millisecond values move to the previous second.
Epoch milliseconds Use the entered value as the UTC millisecond count. Microsecond and nanosecond rows scale the millisecond count and 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 daylight-saving or historical changes.
Named-zone datetime Apply the selected zone's offset for that date and time. Named-zone availability and rule freshness depend on the browser environment.

Offset signs follow timestamp convention. A wall-clock value of 2024-07-01T09:00 at +05:30 is five hours and thirty minutes ahead of UTC, so the UTC instant is 2024-07-01T03:30:00.000Z. At -04:00, UTC is four hours later than the wall clock.

UTC date parts are derived from the UTC instant, not from the selected-zone calendar. Day of year starts at 1 on January 1 UTC. ISO week uses the Thursday-based week-year rule, so the ISO week-year can differ from the calendar year around late December and early January.

Output Meaning Check carefully when
Selected zone ISO Local date and time in the selected zone, including the offset suffix. The instant 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 calculated from the UTC millisecond count. Another source rounds to fewer decimal places.
Selected Day Timeline Four selected-zone checkpoints at 00:00, 06:00, 12:00, and 18:00. You need a complete hourly schedule or a daylight-saving transition audit.
UTC Year Progress The UTC ordinal day divided by 365 or 366. You need elapsed-year percentage by hour, minute, and second.

Custom offsets normalize to ±HH:MM. Hours above 23 are capped at 23, minutes above 59 are capped at 59, and non-matching text resolves to +00:00. Named-zone conversion is only as complete as the named zones available to the browser.

Accuracy Notes:

Epoch conversion is deterministic after the unit and zone rule are known, but several limits still affect how the converted value should be used.

  • The Date and time input captures minutes, so seconds and milliseconds usually come from the timestamp path.
  • Named-zone results depend on browser-supported zone data. A fixed offset is safer when the original record stores only a numeric offset.
  • Leap seconds are not represented as separate 23:59:60 output values.
  • Very old, very large, fractional, or negative values may differ across systems that store timestamps with different ranges or rounding rules.

Worked Examples:

These cases show the checks that usually prevent timestamp mistakes: unit choice, regional display, fixed-offset arithmetic, and negative rounding.

Log timestamp with a regional view

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 was five hours behind UTC at that instant.

Browser-style millisecond value

A telemetry payload carries 1719838800000. Choose milliseconds. Epoch (s) resolves to 1719838800, ISO 8601 (UTC) becomes 2024-07-01T13:00:00.000Z, and the Julian Day value is 2460493.04167. If the same number were treated as seconds, the result would be far outside the expected event window.

Wall-clock time with a fixed offset

A record says 2024-07-01T09:00 at +05:30. Enter the date in Date and time, choose Custom offset, and set +05:30. ISO 8601 (UTC) is 2024-07-01T03:30:00.000Z. If the source was actually a regional zone with daylight-saving changes, use Named time zone instead of assuming the offset is valid for every date.

Negative millisecond boundary

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

FAQ:

Should I choose seconds or milliseconds?

Use seconds for many Unix log and API values, and milliseconds for browser-style timestamps. A date far beyond the expected range often means milliseconds were read as seconds; a modern event near 1970 often 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. Compare 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 record was measured at those precisions.

Why did my custom offset become UTC?

The offset field accepts +HH:MM or -HH:MM. Text that does not match that shape resolves to +00:00, so re-enter the value as something like +05:30 or -08:00.

Are entered timestamps sent to a lookup service?

No timestamp lookup service is needed for the conversion. The timestamp, date parts, zone display, charts, and JSON are derived 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: