Convert Unix epoch seconds, milliseconds, microseconds, and nanoseconds to exact epoch values plus ISO 8601, UTC, and browser-local dates. Batch extraction identifies candidate units with explicit warnings, preserves 18-plus-digit nanosecond values with integer arithmetic, and requires a complete offset-bearing ISO input for reverse conversion. Local-time output names the browser's IANA zone; leap seconds and zone-less dates are not silently invented.
Continue with a related workflow or open the next tool that usually follows this task.
A cron expression is not a complete schedule until its field dialect, IANA time zone, starting instant, DST behavior, and missed-run policy are known. This workflow first converts every reference date to an explicit ISO 8601 instant, then inspects a five-field Unix cron expression field by field, compares future runs in local wall time and UTC, exercises a daylight-saving transition, and verifies the same cases in the production scheduler before a job is enabled.
OpenRelated toolConvert CSV and JSON locally with text-safe typing, strict structure checks, and protected spreadsheet output.
OpenRelated toolFormat explicit ISO instants and inspect five-field Unix cron schedules with IANA zones and DST-aware next runs.
OpenRelated toolParse bounded HTTP header blocks locally with default secret masking and protocol diagnostics.
OpenChoose Timestamp -> Date for an epoch value, copied log lines, or a payload fragment.
Leave Input unit on Auto for ordinary epoch values, or select the documented unit when the value is ambiguous.
Paste up to 200,000 UTF-8 bytes, 200 lines, and 100 timestamp candidates, then review detected units and warnings.
Use exact epoch fields for precision-sensitive work; use ISO 8601 or UTC for a shared incident timeline.
Use the labeled browser-local IANA zone only when matching a user's displayed time or regional schedule.
Choose Date -> Timestamp and enter a complete ISO date with Z or an explicit offset to create four epoch units.
Extract created_at, updated_at, processed_at, and received_at values from copied log lines while ignoring short HTTP codes and counters.
Normalize events from services that emit seconds, milliseconds, microseconds, or nanoseconds into one UTC incident timeline.
Check database exports and event streams without losing the exact sub-millisecond epoch value used for ordering.
Read JWT NumericDate claims as seconds and compare exp, nbf, and iat boundaries without treating conversion as signature validation.
Create deterministic seconds-through-nanoseconds fixtures from one explicitly zoned ISO date for API and queue tests.
Compare a UTC event with the browser's labeled IANA time zone when reconstructing a user report or scheduled action.
Auto-detection uses integer length: 9-11 digits for seconds, 12-14 for milliseconds, 15-17 for microseconds, and 18 or more for nanoseconds. Historical, padded, or domain-specific values can be ambiguous, so select the documented unit when you know it.
A date without Z or an explicit offset depends on an unstated local zone. This converter rejects zone-less dates instead of silently changing the instant on another computer.
ISO and JavaScript Date output stops at milliseconds. The exact microsecond and nanosecond epoch fields remain intact, but the readable date cannot display those remaining digits.
Server logs should normally be correlated in UTC. Browser-local output follows the displayed IANA zone and daylight-saving rules, so it may differ from a fixed offset at another date.
JWT exp, nbf, and iat are NumericDate values expressed in seconds. Interpreting them as milliseconds creates a date close to January 1970 and can hide a token-boundary error.
A 12-digit historical value is milliseconds, not seconds. The exact epoch equivalents all represent the same instant.
946684800000Unit: milliseconds
ISO 8601: 2000-01-01T00:00:00.000Z
Seconds: 946684800
Milliseconds: 946684800000
Microseconds: 946684800000000
Nanoseconds: 946684800000000000Copied log lines can contain all four supported units. Short status codes and counters are not treated as bulk timestamp candidates.
created_at=1704067200 status=200
updated_at=1704067200123 duration_ms=42
processed_at=1704067200123000
received_at=1704067200123000000Detected: 4
Seconds: 1
Milliseconds: 1
Microseconds: 1
Nanoseconds: 1
ISO 8601: 2024-01-01T00:00:00.000Z and 2024-01-01T00:00:00.123ZThe +09:00 offset identifies the instant unambiguously. Four exact epoch representations are generated from the validated date.
2024-01-01T09:00:00.123+09:00Seconds: 1704067200.123
Milliseconds: 1704067200123
Microseconds: 1704067200123000
Nanoseconds: 1704067200123000000
ISO 8601: 2024-01-01T00:00:00.123ZUnix or POSIX time represents elapsed nominal seconds from 1970-01-01T00:00:00Z. It is independent of a display time zone and does not assign a separate epoch value to a leap second.
The conversion core scales decimal input into integer nanoseconds before deriving seconds, milliseconds, microseconds, and nanoseconds. This avoids the rounding that occurs when 16- or 19-digit values pass through JavaScript Number.
Auto mode classifies 9-11 integer digits as seconds, 12-14 as milliseconds, 15-17 as microseconds, and 18 or more as nanoseconds. An explicit unit override is the authoritative choice when source documentation is available.
Date-to-timestamp mode requires YYYY-MM-DDTHH:mm:ss with optional one-to-three millisecond digits and either Z or an offset no larger than +14:00 or -14:00. Month lengths, leap years, clock fields, and offsets are checked before Date parsing.
JavaScript Date and ISO output display milliseconds. For negative sub-millisecond instants, the display is floored to the containing millisecond while exact epoch strings keep the remainder. Relative month and year labels are approximate; local output names the browser's IANA zone so daylight-saving behavior is visible.
Auto mode uses the integer digit count: 9-11 seconds, 12-14 milliseconds, 15-17 microseconds, and 18 or more nanoseconds. It is a practical heuristic, not metadata. Choose an explicit unit for padded, historical, or otherwise ambiguous values.
Yes. Exact calculations use integer arithmetic, so a 19-digit nanosecond value is not rounded through JavaScript Number. ISO, UTC, and local date displays have millisecond precision; a warning identifies any retained sub-millisecond remainder.
Date-to-timestamp mode accepts a complete ISO 8601 date and time with Z or an explicit offset, for example 2024-01-01T00:00:00Z or 2024-01-01T09:00:00.123+09:00. It rejects zone-less dates and impossible calendar values such as February 30.
Unix/POSIX time counts nominal seconds from 1970-01-01T00:00:00Z and does not represent leap seconds as separate epoch seconds. The converter therefore rejects a seconds field of 60.
UTC is the stable choice for correlating servers and incident timelines. Local output uses the browser's displayed IANA time zone, including its daylight-saving rules, and is useful when matching a user's screen or support report.
Timestamp input is limited to 200,000 UTF-8 bytes, 200 lines, and 100 detected candidates. Zoned date input is limited to 128 UTF-8 bytes. These exact limits keep live browser processing and result rendering bounded.
Conversion runs in this browser and the pasted values are not sent to a conversion server. With consent, analytics may receive only the direction, selected unit, aggregate result and warning counts, duration, and error category, never the timestamp values or log text.
JWT exp, nbf, and iat follow NumericDate and are normally epoch seconds. Decode only the relevant numeric claim, keep clock skew and signature validation separate, and do not paste a secret-bearing token when the number alone is sufficient.
Maintained and tested by SimpleWebUtilsReviewed
Method: This check paired the exact “Extract four units while ignoring short counters” input with Unix Timestamp Converter. We followed “Copy the smallest useful context”, captured the result after “Check the documented source unit”, and compared it with the example while treating “Pasting secrets with the timestamps” and “Using auto-detection as authoritative metadata” as explicit boundary questions.
Expected result: The extractor classified second, millisecond, microsecond, and nanosecond values separately, ignored the short duration counter, and retained sub-millisecond precision where a Date cannot.
Sources and standards
Use these focused guides when you need a practical workflow before opening the tool.
A cron expression is not a complete schedule until its field dialect, IANA time zone, starting instant, DST behavior, and missed-run policy are known. This workflow first converts every reference date to an explicit ISO 8601 instant, then inspects a five-field Unix cron expression field by field, compares future runs in local wall time and UTC, exercises a daylight-saving transition, and verifies the same cases in the production scheduler before a job is enabled.
Workflow guideUse this workflow to turn a small, redacted log or payload sample into reviewable timestamp rows while preserving field names, source lines, exact epoch precision, and explicit unit decisions.
Workflow guideUse this workflow after you have identified the timestamp fields and need to order cross-system events, separate event time from ingest time, account for clock skew, and explain the result without overstating causality.
Workflow guideUse this workflow to determine whether a request occurred before nbf, at or after exp, or inside the stated token window, while documenting clock-skew policy and removing the raw token from shared evidence.
Continue with another maintained workflow
Convert CSV and JSON locally with text-safe typing, strict structure checks, and protected spreadsheet output.
Format explicit ISO instants and inspect five-field Unix cron schedules with IANA zones and DST-aware next runs.
Parse bounded HTTP header blocks locally with default secret masking and protocol diagnostics.
Beautify or minify strict JSON locally while preserving duplicate keys and number text.
Strictly decode JWT structure and time claims locally without verifying the signature.