Timestamp converter

Timestamp Converter treats a string of 9 through 13 decimal digits as a Unix timestamp. Values with 9 or 10 digits are interpreted as seconds and multiplied by 1,000. Values with 11, 12, or 13 digits are interpreted as milliseconds. Any other input is passed to JavaScript's Date parser as a date-time string.

The digit-count rule is convenient for current-era timestamps but it is not a universal unit detector. An 11-digit seconds value from a far-future system will be mistaken for milliseconds. A short millisecond value near the Unix epoch will be treated as a date string or rejected rather than identified as milliseconds. Know the producer's unit whenever possible.

A valid result prints local time, UTC, ISO 8601, Unix seconds, and Unix milliseconds. The source is represented at millisecond precision because that is the precision of JavaScript Date. Finer fractions such as microseconds and nanoseconds are not preserved.

Unix time counts from 1970-01-01T00:00:00Z. Many APIs use whole seconds, while JavaScript Date and numerous event systems use milliseconds. A current seconds timestamp has about 10 digits; a current milliseconds timestamp has 13. Confusing them moves the interpreted date by a factor of 1,000.

If a supposed current timestamp converts to a date in January 1970, a milliseconds-versus-seconds mistake is likely. If it produces a date thousands of years away or fails the Date range, seconds may have been treated as milliseconds or vice versa. Check the API field name and schema for hints such as `_ms`, `epochMillis`, or explicit unit documentation.

The output provides both units. Unix seconds are calculated with Math.floor from the millisecond value, so any fractional second is rounded down to the containing Unix second. Unix milliseconds preserve the Date value as an integer. Use the unit required by the destination instead of copying whichever number looks familiar.

A Unix timestamp identifies an instant independent of time zone. The UTC and ISO lines show that instant in UTC. The Local line formats it using the browser's locale and system time zone. Two people in different zones can see different local clock readings for the same epoch value while the UTC and Unix lines remain equivalent.

Date-time strings need an explicit zone when they represent a shared instant. `2026-08-04T15:00:00Z` names 15:00 UTC. An offset such as `+01:00` identifies another local representation of an instant. A string without `Z` or an offset may be parsed as local time depending on its form, which makes results depend on the device.

For logs, APIs, and incident timelines, prefer ISO strings with `Z` or a numeric offset. Preserve the original zone information in records even after converting to UTC. UTC simplifies comparison, but the originating offset can matter for legal, operational, or user-facing context.

Copy the timestamp without a field name, comma, quotation marks, or log prefix. Run Timestamp Converter and compare the UTC line with nearby events. If the numeric input has 10 digits, confirm that the source documents seconds. If it has 13, confirm milliseconds. Do not rely on length alone when the value comes from archival or future-dated data.

For a date-time input, add the intended offset before conversion when the source omitted it and you know the zone. Do not guess a zone from the server's office location because cloud systems and containers often run in UTC. Ask which clock produced the value and how it serialized local time.

When preparing an API parameter, copy the exact requested output line. A field expecting Unix seconds should not receive the 13-digit millisecond value. Add a unit suffix in variable names and tests, such as `expiresAtSeconds` or `createdAtMs`, to prevent later confusion.

Inputs outside the 9-to-13-digit pattern depend on JavaScript Date parsing. ISO 8601 forms are the safest portable choice. Locale-shaped strings such as `04/08/2026` are ambiguous because one reader may mean April 8 and another August 4. Browser and runtime parsing behavior can differ for nonstandard forms.

A date-only ISO string such as `2026-08-04` has semantics that can surprise when displayed locally because the parsed instant is tied to UTC rules. If you mean a local calendar date rather than an instant, a Unix timestamp may be the wrong data model. Calendar dates such as birthdays and billing days often need a date type without time or zone.

Leap seconds are not represented as distinct JavaScript Date instants. Historical local time can also depend on time-zone database rules that this simple converter does not expose. Use a date-time library and authoritative zone data for scheduling, historical research, or civil-time calculations beyond straightforward inspection.

Local clocks can skip or repeat times during daylight-saving transitions. A local time such as 02:30 may not exist on a spring transition day, while 01:30 may occur twice during a fall transition. An explicit UTC instant removes the ambiguity, but converting a zone-free local string cannot recover which occurrence the producer intended.

Check events near midnight in both UTC and the relevant business zone. The same instant can belong to different calendar dates. This matters for daily reports, token expiry, billing cutoffs, and audit windows. A display that says Tuesday locally may still be Monday in UTC.

When comparing two values, convert both to Unix milliseconds or another single unit before subtraction. Do not subtract formatted local strings. For service-level calculations, define whether boundaries are inclusive and how clock skew is handled. The converter displays values but does not apply tolerance or business rules.

An invalid-date error means JavaScript could not construct a Date from the input or the numeric value fell outside its supported range. Remove labels and confirm the string uses a recognized ISO form. Check for hidden spaces, decimal separators, a negative sign, or more than 13 digits, all of which bypass the numeric unit rule.

A plausible but wrong date is more dangerous than an error. Compare against a known event, inspect digit count, and calculate whether the magnitude fits seconds or milliseconds. For JWT `exp`, `iat`, and `nbf`, specifications use numeric dates in seconds, even though JavaScript code often multiplies them by 1,000 to build a Date.

If the Local line looks wrong while UTC is correct, check the operating system time zone and daylight-saving setting. The workbench does not offer a zone selector. Use a zone-aware library when you must display an instant in a zone other than the browser's configured one.

Use JWT Decoder to expose numeric date claims, then use this converter to view them. Remember that decoding does not verify the token. Use JSON Formatter to inspect timestamps inside an API response, but preserve large integer values carefully because JavaScript JSON parsing can lose precision beyond the safe integer range.

Regex Tester can locate date-like text in logs, yet a match does not prove the date is valid or unambiguous. Hash Generator fingerprints exact text and does not understand temporal equivalence. Two different ISO strings can name the same instant while producing different hashes.

Production code should parse only documented formats, carry units in names and types, store instants in a consistent representation, and format them at the user boundary. Test seconds, milliseconds, leap days, zone offsets, daylight-saving transitions, epoch boundaries, invalid dates, and values around rounding points. The browser tool helps inspect one value; code and tests enforce the time contract.

JavaScript Date stores an integer number of milliseconds. A source timestamp with microsecond or nanosecond precision loses its extra digits if it is converted through Date. Keep the original high-precision value in an integer, decimal, or time type that supports the required scale.

Database timestamp types differ in whether they store an instant, a local date-time, an offset, or a zone. A column name alone may not reveal the behavior. Check the database type, driver conversion, server time zone, and serialization format before comparing it with browser output.

Round trips should preserve the intended concept. Convert an instant to ISO and back, then compare Unix milliseconds. For a local calendar event, preserve the zone and local fields separately when the schedule must follow future daylight-saving rules.

Large epoch values can exceed JavaScript's safe integer range or Date's supported range. JSON parsing can round oversized numeric timestamps before the converter even sees them. Carry high-range values as strings and validate them with an appropriate big-integer or date-time library.

Negative Unix timestamps represent instants before 1970, but the workbench's numeric shortcut accepts digits only. A negative value goes through date-string parsing and may be rejected or interpreted unexpectedly. Use code with an explicit numeric unit for pre-epoch work.

Durations are not timestamps. The number `3600` may mean one hour, but it does not identify an instant without an origin. This converter does not add durations, parse ISO duration strings, or calculate calendar intervals. Keep duration units explicit and use duration-aware functions.

When exporting data, include a schema note with unit, precision, and zone semantics. A column called `time` invites mistakes. Names such as `occurred_at_epoch_ms` or an ISO field ending in `_utc` make the contract easier to test and review.

Token and cache expirations need comparison against the correct clock. A displayed future `exp` does not prove a token is usable because issuer, audience, signature, and revocation still apply. Cache `max-age` is a duration, not an epoch timestamp. Log ingestion can add a second timestamp beside the event's own time, so identify if the field records creation, receipt, processing, or storage. Keep each field separate in incident timelines and note its source system.