Epoch Time Converter

A timestamp becomes reliable only when its unit and time-zone assumption travel with it. The number 1719838800 can identify a 2024 instant when read as epoch seconds, but the same digits as milliseconds point to a date in January 1970. Digit count is a clue, not a rule, so the source system's unit must be known.

Unix epoch time measures elapsed seconds or milliseconds from 1970-01-01 00:00:00 UTC. A wall-clock value works in the other direction: a calendar date and local time need an offset or named-zone rule before they identify one instant. The same instant can then appear on different dates in Kuala Lumpur, New York, and UTC without any contradiction.

Daylight-saving changes create two difficult cases. During a spring jump, some local times never occur. During a fall-back transition, one clock reading can occur twice. Rejecting a nonexistent time prevents a silent one-hour shift; choosing between repeated times requires a documented policy or a known offset.

Time-zone law can change after software is written. Regional names are more meaningful than fixed offsets, but only when their rule data covers the date in question. Regional conversion based on a fixed contemporary rule subset cannot replace a live copy of the Internet Assigned Numbers Authority (IANA) database, so future or historical legal-time work needs current verification.

How to Use This Tool:

Begin with the source system's known unit or wall-clock rule, not with the apparent length of the value.

1. Choose Start from: epoch seconds, epoch milliseconds, or a wall-clock date and time. Seconds may contain a fraction only when it resolves to a whole millisecond; milliseconds must be an integer.
2. Enter the timestamp explicitly. For wall-clock input, provide the local date and minute shown by the source.
3. Select UTC, a signed UTC offset in +HH:MM or -HH:MM form, a supported named zone, or a supported device zone.
4. Read the UTC instant and selected-zone timestamp together. Keep the source unit and effective offset with any copied value.
5. Review the zone comparison and accuracy notes before using regional dates near a daylight-saving transition or outside the documented rule window.

Interpreting Results:

ISO UTC is the canonical millisecond instant and ends in Z. Selected-zone ISO represents that same instant with a date-specific offset. If their clock times or calendar dates differ, the conversion can still be correct.

• Confirm whether the source was seconds or milliseconds. A plausible-looking date does not prove the unit.
• For a named zone, retain both the zone name and effective offset. The name carries regional meaning; the offset proves what applied at that instant.
• ISO week-year may differ from calendar year near New Year's Day. Read ISO week together with ISO week year.
• Julian day, modified Julian day, and year progress are derived coordinates. They do not validate that the source event was recorded at the correct time.

Technical Details:

The canonical coordinate is a whole number of milliseconds. Calendar conversion uses the proleptic Gregorian leap-year rule across years 0001 through 9999. Negative epoch values represent instants before 1970. Leap seconds are not represented, and precision finer than one millisecond is rejected rather than implied.

Formula Core:

Seconds and fixed-offset wall clocks are reduced to the same millisecond coordinate:

t_s is epoch seconds, t_civil is the wall-clock fields treated as a zero-offset calendar coordinate, and o_min is the signed offset in minutes. For 2024-07-01T09:00 at +05:30, subtracting 330 minutes gives 2024-07-01T03:30:00.000Z and epoch 1,719,804,600 seconds.

Julian and modified Julian day are direct transforms of the epoch coordinate:

Rule Core:

Fixed offsets never change with season. Named zones use the following declared rules; zones with daylight-saving transitions are supported only from 2007 through 2099. Fixed-rule named zones keep their listed offset outside that window.

A wall-clock time inside a daylight-saving gap is rejected. If a fall-back time matches both seasonal offsets, the earlier of the two possible instants is selected. Epoch input avoids that ambiguity because it already identifies the instant.

Year progress divides elapsed milliseconds since January 1 UTC by the full UTC year length. Day of year begins at 1, quarters use calendar months, and ISO weeks begin on Monday with week 1 containing January 4. RFC-style output is shown to whole seconds, while ISO output retains three millisecond digits.

Accuracy Notes:

• Named-zone rules are a documented subset, not a live full time-zone database. Verify legal-time changes for operational, historical, or future schedules.
• Regional daylight-saving rules are bounded to 2007–2099. Fixed offsets and fixed-rule named zones do not model political changes.
• The supported calendar range is year 0001 through 9999 and the internal coordinate is whole milliseconds.
• Leap seconds and submillisecond precision are outside scope.

Worked Examples:

References:

• RFC 3339: Date and Time on the Internet, RFC Editor, July 2002.
• Time zone and daylight saving time data, Internet Assigned Numbers Authority.
• Converting Between Julian Dates and Gregorian Calendar Dates, U.S. Naval Observatory.