Toolarithm

Unit Converter

Unix Timestamp Converter

Exact instants. Explicit date rules.

Convert a timestamp

Epoch units and UTC dates.

Signed decimal or scientific value. Select the unit explicitly; subnanosecond precision is rejected.

UTC, Dubai and New York remain in complete exports, alongside this runtime-supported named zone.

This converter uses POSIX-style epoch time through nanosecond resolution, with UTC years 0001 through 9999. Leap-second labels, timezone-free date strings and guessed timestamp units are not accepted. Named-zone rules depend on installed browser data.

Optional elapsed comparison
Report sections

Numeric input allows forty significant digits and written exponents from negative thirty through thirty, within the supported UTC range. All exact units and hidden views/working remain in complete exports. Native Date objects only retain whole milliseconds; the exact nanosecond value is stored separately.

Worked examples
View timestamp results

Exact UTC date-time

2026-06-10T12:00:00.000Z

The explicit timestamp unit was used without digit-count guessing.

Exact timestamp units

Seconds

t=1781092800 st=1781092800\,\mathrm s

Milliseconds

t=1781092800000 mst=1781092800000\,\mathrm{ms}

Microseconds

t=1781092800000000 μst=1781092800000000\,\mathrm{\mu s}

Nanoseconds

t=1781092800000000000 nst=1781092800000000000\,\mathrm{ns}

These are exact decimal representations of the entered instant, through nanosecond resolution. More digits do not establish clock accuracy or imply native Date objects retain nanoseconds.

Containing millisecond and precision remainder

M=⌊tms⌋=1781092800000M=\left\lfloor t_{\mathrm{ms}}\right\rfloor=1781092800000r=0 nsr=0\,\mathrm{ns}⌊ts⌋=1781092800\left\lfloor t_s\right\rfloor=1781092800

Whole-millisecond floor as UTC: 2026-06-10T12:00:00.000Z

Floor means the whole timestamp at or before the instant. A negative fraction therefore moves to the preceding integer, unlike truncation toward zero. The complete exact instant stays in the primary result and all exact unit rows.

Named timezone views

Every view describes the same instant. Offsets come from installed runtime rules; historical offsets may include seconds. A local year outside the four-digit profile is reported explicitly while the UTC conversion stays valid.

UTC

2026-06-10 12:00:00.000

UTC+00:00

Named-zone rules come from installed browser/runtime data; fractional digits are retained separately.

Asia/Dubai

2026-06-10 16:00:00.000

UTC+04:00

Named-zone rules come from installed browser/runtime data; fractional digits are retained separately.

America/New_York

2026-06-10 08:00:00.000

UTC-04:00

Named-zone rules come from installed browser/runtime data; fractional digits are retained separately.

Step-by-step Unix timestamp conversion

  1. 1. Normalize the explicit timestamp unit

    Choose the unit deliberately. Parse the signed decimal exactly into integer nanoseconds; values below nanosecond precision are rejected rather than rounded.

    N=109ts=106tms=103tμs=tnsN=10^9t_s=10^6t_{\mathrm{ms}}=10^3t_{\mathrm{\mu s}}=t_{\mathrm{ns}}

  2. 2. Resolve the calendar representation

    Offset-qualified input subtracts its explicit offset. Named-zone input resolves gaps and repeated occurrences explicitly. Leap-second labels and device-local parsing are not inferred.

    TUTC=L−oT_{\mathrm{UTC}}=L-o

  3. 3. Separate containing milliseconds from exact precision

    Floor the whole-millisecond count and retain the nonnegative submillisecond remainder. This is an explicit containing-millisecond convention, not JavaScript TimeClip truncation toward zero.

    M=⌊N106⌋,N=106M+r,0≤r<106M=\left\lfloor\frac{N}{10^6}\right\rfloor,\qquad N=10^6M+r,\quad0\le r<10^6
What Can You Create?

Convert exact epoch values, explicit dates and independent log lines

Inspect an epoch timestamp

Choose a unit explicitly and compare the same instant in seconds, milliseconds, microseconds and nanoseconds. Signed fractions and large integer values remain exact within the supported four-digit UTC-year profile.

Resolve a qualified calendar representation

Use a complete offset date or an explicit local date and named zone. Invalid calendar dates and DST ambiguity are handled deliberately, while the device timezone is never used as an unstated interpretation.

Review independent batch records

Paste numeric timestamps or offset-date lines and preserve each outcome. Invalid records retain line numbers and errors without erasing valid conversions, and complete CSV retains exact units and original raw values.

Unix timestamp formulas and worked examples

Normalize explicit units to integer nanoseconds

Let NN be the integer nanosecond count relative to the epoch. Seconds, milliseconds and microseconds are different decimal scalings of the same value. A timestamp unit is an explicit input, not a guess based on the number of digits. The original example uses 1781092800 s1781092800\,\mathrm s and resolves to noon UTC on June 10, 2026. Its integer nanosecond representation can be retained without converting that large integer into a floating-point value first.

N=109ts=106tms=103tμs=tnsN=10^9t_s=10^6t_{\mathrm{ms}}=10^3t_{\mathrm{\mu s}}=t_{\mathrm{ns}}

Example: one nanosecond before the epoch

A value of −1 ns-1\,\mathrm{ns} belongs to the final fractional second before the epoch. Its containing whole second is the preceding second, and its containing whole millisecond is the preceding millisecond. Keeping the exact fraction separately allows the canonical UTC string to end with all nine supported fractional digits. Truncating the count toward zero would identify the wrong containing unit for this negative example. The lower-precision representation is labeled rather than substituted for the primary exact instant.

ts=−0.000000001 s,M=−1,r=999999 nst_s=-0.000000001\,\mathrm s,\qquad M=-1,\quad r=999999\,\mathrm{ns}

Preserve the containing-millisecond remainder

The converter uses a floor quotient for whole milliseconds and retains the nonnegative remainder. For a negative count, this differs from truncation toward zero. The exact pair reconstructs the original integer count, so lower-precision native Date formatting does not destroy the nanosecond information stored by the tool. The separately labeled millisecond ISO string is a representation of the floor value; it is not claimed to be the full original instant when a nonzero remainder exists.

M=⌊N106⌋,r=N−106M,0≤r<106M=\left\lfloor\frac{N}{10^6}\right\rfloor,\qquad r=N-10^6M,\quad0\le r<10^6

Resolve an explicit offset before displaying other zones

An offset-qualified date identifies an instant by subtracting its numeric offset from the stated local calendar value. The instant can then be projected through another named zone’s offset at that instant. Named-zone entry has an additional step: a wall time can be skipped or repeated, so the supported local-input profile checks candidates and requires a repeated-time choice. Display views retain the nanosecond fraction separately from native date formatting and do not infer a local zone from an abbreviation.

TUTC=L−o,Li(T)=T+oi(T)T_{\mathrm{UTC}}=L-o,\qquad L_i(T)=T+o_i(T)

Compare a reference without changing the source

The optional comparison subtracts the source instant from a separately entered reference instant. If the reference is earlier, the difference is negative. The calculation retains integer nanoseconds before expressing the elapsed result in seconds. This operation uses the stated POSIX-style epoch model; it does not count named-zone calendar dates, apply business-day rules or add distinct leap-second labels. Batch mode keeps its independent line outcomes instead of applying one reference comparison to an entire collection.

ΔN=Nreference−Nsource,Δts=ΔN109\Delta N=N_{\mathrm{reference}}-N_{\mathrm{source}},\qquad \Delta t_s=\frac{\Delta N}{10^9}
Why Users Love This Tool

Separate exact instants, display precision and calendar interpretation

Predictable numerical behavior

  • Integer nanoseconds retain exact input precision beyond native floating-point integer limits.
  • Containing whole milliseconds use a labeled floor with a nonnegative precision remainder.
  • Strict calendar checks reject impossible dates, unqualified strings and unsupported leap-second labels.

Complete, reusable context

  • Lossless single-result round trips preserve supported fractional digits.
  • Complete text and CSV retain hidden views, working and independent batch errors.
  • Validated sharing, explicit device-clock capture, copy feedback and a deferred print guard support a reviewable workflow.
Perfect For

Useful for logs, APIs and careful time-data inspection

People reviewing logs and exported data

Compare explicitly labeled epoch units, retain pre-epoch fractions and inspect one result per source line. The tool does not guess a unit from string length or discard invalid lines from the exported audit trail.

People checking API date fields

Verify offset-qualified dates and their UTC interpretation without relying on permissive host-local parsing. Named-zone entry is available when the source represents a local wall time with an explicitly supplied zone.

Students learning timestamp conventions

Explore the epoch, signed values, unit factors, floor versus truncation and submillisecond precision. Distinguish a stored numerical instant from the accuracy of the clock that originally produced it.

How It Works

How it works in three quick steps.

1

Choose the input method and its interpretation

Choose a numeric timestamp with an explicit seconds, milliseconds, microseconds or nanoseconds unit; a complete offset-qualified date-time; a local date in a named zone; or independent batch lines. Numeric input supports signed decimals and scientific notation. Offset dates require seconds and Z or a numeric offset. Named-zone input uses dates from 2000 through 2099 and an explicit earlier/later choice when the wall time repeats.

2

Review exact precision and timezone context

Inspect the canonical UTC instant, exact unit values and separate containing-millisecond floor with its nanosecond remainder. Choose another named display zone when needed. A skipped local time or unsupported subnanosecond value clears stale output rather than being guessed or rounded. In batch mode, every nonblank source line receives its own result or error. A reference instant can be compared separately in single-conversion modes.

3

Copy, round-trip or save the complete record

Copy canonical UTC or exact Unix seconds, load a single result into the other input method, share validated single-conversion settings or download complete CSV. Batch data uses copying and CSV rather than share URLs. Capture the current device time only when you want a new millisecond-precision snapshot. Print or save PDF for the visible report; complete exports retain hidden unit, timezone and working context.

Download & Print

Save the instant with its unit, source and precision context

Copy exact output or a single-conversion link

Copy canonical UTC, exact Unix seconds or a full plain-text record. Share links retain validated active single-conversion settings. A result can be loaded into date or numeric input without dropping fractional digits.

Download complete CSV

UTF-8 CSV retains raw batch lines, explicit errors, exact unit values, floor/remainder fields, named-zone views and generated working. Hidden sections are retained in the saved record, so report filters do not remove the evidence needed to interpret an instant.

Print or save PDF

Print the current single or batch report, with the selected visible sections. Batch raw excerpts are limited for readable pages while complete values remain in CSV. Choose the browser’s PDF destination and review scale before saving.

FAQ

Frequently Asked Questions

What does a Unix timestamp count?
This converter uses the POSIX-style epoch beginning at January 1, 1970, at midnight UTC. A positive value is after that epoch and a negative value is before it. The selected unit determines the scale: tms=1000tst_{\mathrm{ms}}=1000t_s. This numerical model does not count leap-second labels as additional distinct timestamps. The converter’s human-readable UTC profile spans years 0001 through 9999, and the displayed digits describe the entered model rather than proving a device clock was accurate to that precision.
How do I distinguish seconds, milliseconds, microseconds and nanoseconds?
Choose the unit explicitly rather than guessing from digit count. The same digits can describe very different dates under different units, especially near the epoch or for historical values. Exact nanoseconds satisfy N=109ts=106tms=103tμsN=10^9t_s=10^6t_{\mathrm{ms}}=10^3t_{\mathrm{\mu s}}. The tool displays all four terminating-decimal representations of one instant. Numeric scientific notation is accepted within documented bounds, but an input requiring a fraction smaller than one nanosecond is rejected instead of silently rounded.
Why do negative fractional timestamps need special care?
A negative fraction refers to an instant before the epoch. For example, −0.001 s-0.001\,\mathrm s is one millisecond before midnight UTC at the epoch, not the epoch itself. This tool separates exact precision from containing whole units. The whole-second floor is −1-1 for that example, while truncation toward zero would produce zero. Floor values are labeled explicitly and do not replace the exact unit values. The nanosecond remainder is retained so a lower-precision display never becomes an undisclosed loss of information.
Which date strings are accepted, and are invalid dates normalized?
Offset-date entry uses a strict four-digit Gregorian date, T, hours, minutes and seconds, an optional fraction of at most nine digits, and Z or a numeric offset. It does not accept timezone-free strings, informal dates, impossible dates, an hour of twenty-four or leap-second labels. Calendar components are checked rather than rolled into a different month. The negative-zero offset convention resolves the known UTC instant without inventing a local named zone. The supported UTC range is narrower than the full native JavaScript Date range.
Can I convert a local time in a named timezone?
Yes. Select local named-zone input, enter a date from 2000 through 2099 and a local clock value, then provide a runtime-supported IANA identifier. Seconds and up to nine fractional digits are optional in that entry method. A skipped local time is rejected. A repeated local time requires an explicit earlier or later occurrence, and the report preserves both alternatives. Timezone rules come from the installed browser/runtime and can change after political updates; the tool does not substitute the device’s local zone silently.
Does JavaScript Date preserve the displayed nanoseconds?
No. The exact timestamp is retained separately as an integer nanosecond value. A native Date representation uses a whole-millisecond value. This tool chooses the containing millisecond with M=⌊N/106⌋M=\lfloor N/10^6\rfloor and retains a nonnegative remainder satisfying N=106M+rN=10^6M+r. That is an explicit floor convention, not a claim that native TimeClip rounds negative fractions in the same way. The primary UTC string and exact unit values keep all supported digits; a separately labeled millisecond ISO string shows the lower-precision representation.
How are batch errors and a reference comparison handled?
Batch mode accepts up to fifty nonblank lines and applies one explicit numeric unit or one offset-date input kind to the batch. Each line is independent: a bad line remains labeled with its source line number and error while valid lines still convert. Complete text and CSV retain all raw values and outcomes. Single-conversion modes can separately compare a reference offset date; the signed elapsed difference is reference minus source. That comparison does not modify the primary instant or perform local calendar-day arithmetic.
What do current-time capture, sharing and downloads preserve?
The current-time button captures the device clock once at millisecond precision; it is not a live clock or a synchronized server-time source. Share links preserve validated single-conversion settings and report preferences. Batch content is exported through copied text or CSV instead. Complete records include every exact unit, floor and remainder, timezone view, active source context, comparison and hidden working. The printed report follows visible choices. UTC/date/time strings and user-entered syntax remain literal data, while mathematical relationships use accessible LaTeX and MathML.
About This Tool

About this Unix Timestamp Converter

The Toolarithm Unix Timestamp Converter gives a stated epoch value or qualified date-time a precise, reviewable interpretation. It preserves the original Unix-second example and its matching offset-date example while extending explicit unit choices through microseconds and nanoseconds. The implementation retains integer nanoseconds rather than converting large timestamp integers into floating-point numbers. Decimal and scientific values are accepted within documented bounds only when they describe a whole number of nanoseconds. The primary UTC profile uses four-digit proleptic Gregorian years from 0001 through 9999; this is a deliberate human-readable scope rather than the full expanded-year range of native Date objects.

Different input methods have different meanings. Numeric timestamps require a selected unit. Offset-date input requires a complete calendar value with an explicit relationship to UTC and rejects impossible dates instead of normalizing them. Local named-zone input uses the previously reviewed timezone-resolution workflow within its supported modern date range. A skipped time is rejected and a repeated time requires an explicit chronological occurrence. These methods resolve one instant, after which named display zones provide local projections. Installed runtime timezone rules supply those projections and can differ across versions or change after regional policy updates.

Precision is kept distinct from presentation. Every exact unit output describes the same instant. A separate containing-millisecond floor and nonnegative nanosecond remainder show how a lower-precision native representation relates to that exact value, including negative fractions before the epoch. The tool does not suggest that printing more digits improves clock accuracy. Its current-time action captures the device clock once at millisecond precision, and its optional reference comparison is an elapsed POSIX-style difference rather than local calendar arithmetic or leap-second accounting.

Independent batch conversion retains one result or error for each nonblank source line. Complete copied records and CSV preserve raw input, all exact units, floors, remainders, display-zone context and hidden working. Single-conversion share links preserve validated active settings; batches use copying and CSV instead. Printed reports follow visible preferences and use compact raw excerpts where a long invalid line would make a page unreadable. The goal is a clear numerical and calendar record whose assumptions stay visible when the result is reused elsewhere.

Editorial Transparency

Who maintains this page

Ownership and review

Written and maintained by the Toolarithm editorial team. No review date is shown without a maintained editorial record. No independent professional review is claimed.

Methodology

Conversion factors are normalized to canonical units and checked in both directions. Exact definitions and offset formulas are preferred over rounded lookup values.

Read the editorial methodology

Dates and sources

Review dates change only after a substantive method or content check.

Keep building

Explore more unit converters

Converters