Unix Timestamp Converter
Convert signed Unix seconds or milliseconds to UTC and a numeric-offset display, or turn a civil date and explicit UTC offset back into an epoch value. Inspect RFC 3339 text, weekday, day of year, ISO week, precision detection, and the signed 32-bit boundary.
epoch
instant
32-bit
POSIX seconds since the Epoch
The Open Group defines “seconds since the Epoch” through a formula based on Coordinated Universal Time and the proleptic Gregorian calendar, with the Epoch at 1970-01-01 00:00:00 UTC. A Unix timestamp is therefore an instant count, not a formatted local date and not a time-zone label.
Milliseconds = seconds × 1,000
UTC instant = civil time − numeric UTC offset
Signed values before the Epoch are negative. Timestamp −1 represents the last modeled second before 1970 UTC. Fractional seconds are permitted by this converter and retained to millisecond display precision. Software ecosystems vary: some APIs accept integer seconds, some use milliseconds, and some use microseconds or nanoseconds.
The auto-detection threshold is a convenience, not a standard. A magnitude of at least one trillion is treated as milliseconds because modern millisecond timestamps are commonly 13 digits, while contemporary second timestamps are 10 digits. Far-future or unusual values can defeat that heuristic, so select the unit manually when the producer is known.
UTC first, numeric offsets second
UTC identifies the instant without relying on local daylight-saving rules. RFC 3339 uses a trailing Z for offset zero and supports numeric offsets such as −05:00. It defines the numeric offset as local time minus UTC; subtracting that offset produces UTC.
This calculator’s fixed-offset display does not apply a named zone such as America/New_York. Named zones include historical and political rule changes, while −05:00 is simply five hours behind UTC for every displayed instant. In New York, −05:00 may describe standard time and −04:00 daylight time, depending on date and current law.
For date-to-timestamp conversion, the civil fields are parsed directly and the entered offset is subtracted. The browser’s own time zone is deliberately ignored. This prevents the same input from encoding differently on computers located in different U.S. zones.
Unix time and leap seconds
UTC can label a leap second as 23:59:60. POSIX elapsed-second conventions and common Unix APIs do not generally provide a unique timestamp label for that extra UTC second in the same way an astronomical time scale would. Implementations may repeat, smear, or otherwise handle it under their system policy.
JavaScript Date does not accept an input second of 60 in the ordinary ISO path used here. The converter therefore models the continuous millisecond scale exposed by Date and does not claim leap-second fidelity. For legal metrology, astronomy, satellite navigation, or distributed systems with leap smearing, use the specified time scale and implementation.
RFC 3339 describes leap-second syntax, while POSIX defines its own seconds-since-Epoch interpretation. The two formats are related but not interchangeable promises about physical elapsed SI seconds across every historical leap event.
Worked 2026 UTC conversion
Timestamp 1,767,225,600 seconds is multiplied by 1,000 to obtain 1,767,225,600,000 milliseconds. Interpreted on the UTC timeline, it becomes 2026-01-01T00:00:00.000Z. The date is a Thursday, day 1 of a 365-day year, and belongs to ISO week 2026-W01.
At offset −05:00, the same instant displays as 2025-12-31 19:00:00.000 UTC−05:00. The timestamp does not change because the underlying instant is the same; only the civil representation changes. Conversely, encoding 2026-01-01 00:00:00 at −05:00 produces 2026-01-01T05:00:00Z and a timestamp five hours larger.
The example is 20,454 days after the Epoch. It remains below 2,147,483,647, the maximum signed 32-bit seconds value, with about 4,401.1 days of range remaining. That boundary occurs in January 2038 and matters to systems that store time in signed 32-bit seconds.
The 2038 boundary and implementation range
| Boundary | UTC meaning | Why it matters |
|---|---|---|
| 0 | 1970-01-01T00:00:00Z | The Unix Epoch reference instant. |
| −1 | 1969-12-31T23:59:59Z in the ordinary model | Demonstrates signed pre-Epoch time. |
| 2,147,483,647 | 2038-01-19T03:14:07Z | Largest signed 32-bit seconds value. |
| 2,147,483,648 | One second later | Overflows a signed 32-bit seconds field unless software uses a wider representation. |
| JavaScript Date limit | Approximately ±8.64 × 10¹⁵ milliseconds | This converter rejects values Date cannot represent, even if a different system supports them. |
The year-2038 issue is a storage and software-compatibility problem, not the end of Unix time as a concept. Systems using signed 64-bit seconds have vastly more range. Databases, file formats, network protocols, embedded devices, and language APIs can each have different boundaries, precision, and invalid-value behavior.
When moving timestamps between systems, record the unit, signedness, width, time scale, and null convention. A 13-digit millisecond value accidentally treated as seconds can land outside the date implementation’s range; a 10-digit seconds value treated as milliseconds lands near January 1970.
Calendar fields are derived in UTC
Weekday, day of year, and ISO week are calculated from the UTC date, not from the fixed-offset display. Around midnight, the offset display may belong to the previous or next civil day while those UTC fields stay tied to the Z timestamp. This choice keeps one reproducible calendar interpretation on the result panel.
Day of year counts January 1 as day 1 and recognizes Gregorian leap years. ISO weeks begin Monday, and week 1 is the week containing the year’s first Thursday. The ISO week year can therefore differ from the calendar year for dates near New Year. A late-December date can belong to week 1 of the following ISO year, and an early-January date can belong to the preceding ISO week year.
If an application needs local weekday, local day of year, or a locale-specific week number, derive those fields after applying the correct named-zone rules. A fixed offset alone cannot reveal future or historical daylight-saving transitions.
A timestamp is not proof of event order
A wall-clock timestamp can be wrong because a device clock drifted, was configured incorrectly, was reset, or was maliciously changed. Network synchronization improves agreement but does not make every recorded value trustworthy. Distributed systems can also observe events in different orders because of latency, buffering, retries, and asynchronous processing.
Security and audit designs should preserve clock source, synchronization status, ingestion time, device identity, sequence numbers, immutable logging controls, and cryptographic integrity where appropriate. Database-generated timestamps and client-provided timestamps have different trust boundaries. A future-looking or duplicate Unix value is a clue, not automatic proof of fraud.
For ordering within one process, use a monotonic counter or clock designed for elapsed time. For ordering across systems, define causal or sequence semantics appropriate to the protocol. Unix time remains useful for civil correlation, but it cannot by itself establish causality.
Input and logging practices
- Store or exchange an unambiguous UTC instant and carry the intended display zone separately.
- Use RFC 3339 with an explicit Z or numeric offset; avoid an unqualified local time in cross-system data.
- Document seconds, milliseconds, microseconds, or nanoseconds in field names and API contracts.
- Keep enough integer width for the product lifetime and dates the application must represent.
- Do not use client wall clocks as trusted security or ordering sources without synchronization and threat analysis.
- Preserve fractional precision only when the originating clock and transport actually support it.
- Test negative timestamps, daylight-saving transitions, leap years, the 2038 boundary, and invalid civil dates.
For monotonic duration measurement, a wall-clock timestamp may be unsuitable because synchronization can adjust system time. Use the platform’s monotonic clock for elapsed intervals and a UTC wall clock for civil records, then define how the two are correlated.
Unix timestamp FAQs
Is Unix timestamp always in seconds?
Traditional Unix time is commonly expressed in seconds, but APIs often use milliseconds, microseconds, or nanoseconds. The number alone does not declare its unit. Inspect documentation or select precision manually.
Does a timestamp contain a time zone?
No. It identifies an instant relative to the Epoch. Time zone or numeric offset is applied when formatting that instant as civil time. Two offset displays can represent the same timestamp.
Why is my 13-digit timestamp invalid?
It may be milliseconds accidentally interpreted as seconds. Modern millisecond timestamps often have 13 digits. Select milliseconds or auto-detect, and confirm the producer’s contract.
Can Unix timestamps represent dates before 1970?
Signed implementations can use negative values, but support varies by operating system, database, and file format. This calculator accepts negative values within JavaScript Date’s representable range.
What happens in 2038?
A signed 32-bit seconds field overflows after 2,147,483,647. Systems using wider time representations are not limited to that instant, but legacy embedded software and stored formats may require remediation.
Does this converter handle daylight saving time?
It handles an explicit fixed numeric offset only. It does not look up named-zone rules or historical daylight-saving changes. Enter the offset that applies to the desired civil time or use a time-zone database.
When the timestamp will be pasted into Discord, format the same moment for Discord’s dynamic display with the Discord timestamp converter.
References
These primary standards and U.S. time resources support the Epoch, RFC 3339, UTC, and unit concepts used here.