About

A Unix timestamp represents the number of seconds elapsed since 1970-01-01T00:00:00Z (the Unix epoch). It is the canonical time representation in POSIX systems, databases, APIs, and logging infrastructure. Getting the conversion wrong by even one hour - a common timezone miscalculation - corrupts event ordering, breaks cache invalidation headers, and produces silent data errors that propagate downstream. This tool performs bidirectional conversion between human-readable dates and Unix timestamps in both seconds (t_s) and milliseconds (t_ms), with explicit timezone offset control. It handles edge cases including dates before the epoch (negative timestamps), leap second boundaries, and the Year 2038 problem threshold at 2,147,483,647.

The converter accepts manual date component entry, ISO 8601 strings, or native datetime picker input. Reverse mode takes a raw timestamp and produces a full UTC and local-time breakdown. Note: this tool assumes the Gregorian calendar and does not account for leap seconds - POSIX time deliberately ignores them, so a day is always exactly 86,400 seconds. Pro tip: always store timestamps in UTC; apply timezone offsets only at the display layer.

Formulas

The Unix timestamp is defined as the total elapsed seconds from the epoch, ignoring leap seconds.

t_s = D_ms − E_ms1000

Where t_s = Unix timestamp in seconds, D_ms = target date in milliseconds since epoch (from Date.getTime()), E_ms = epoch reference (0 for Unix). The millisecond variant is simply:

t_ms = D_ms − E_ms

For timezone-adjusted conversion:

t_utc = t_local − offset × 3600

Where offset is the timezone offset in hours (e.g., +5.5 for IST, −5 for EST). Reverse conversion from timestamp to date components uses modular arithmetic on t_s to extract year, month, day, hour, minute, second via the Gregorian calendar algorithm.

Reference Data

Milestone / Event	Date (UTC)	Unix Timestamp (s)	Notes
Unix Epoch	1970-01-01 00:00:00	0	Origin of POSIX time
First Moon Landing	1969-07-20 20:17:40	−14,182,940	Negative timestamp (pre-epoch)
GPS Epoch	1980-01-06 00:00:00	315,964,800	GPS week zero
1 Billion Seconds	2001-09-09 01:46:40	1,000,000,000	Celebrated by programmers
Y2K	2000-01-01 00:00:00	946,684,800	Millennium rollover
iPhone Launch	2007-06-29 00:00:00	1,183,075,200	Start of smartphone era
Bitcoin Genesis Block	2009-01-03 18:15:05	1,231,006,505	Block #0 mined
Max 32-bit Signed Int	2038-01-19 03:14:07	2,147,483,647	Year 2038 problem (Y2K38)
Max 32-bit Unsigned	2106-02-07 06:28:15	4,294,967,295	Unsigned 32-bit overflow
1.5 Billion Seconds	2017-07-14 02:40:00	1,500,000,000	Another round number
2 Billion Seconds	2033-05-18 03:33:20	2,000,000,000	Approaching Y2K38
JavaScript Max Safe Date	275760-09-13	8,640,000,000,000	Date.max in JS (±100M days)
NTP Epoch	1900-01-01 00:00:00	−2,208,988,800	Network Time Protocol origin
macOS Epoch (Core Data)	2001-01-01 00:00:00	978,307,200	Apple reference date
Windows FILETIME Epoch	1601-01-01 00:00:00	−11,644,473,600	100-nanosecond intervals

Frequently Asked Questions

A discrepancy of exactly 3600 seconds (1 hour) almost always indicates a timezone or daylight saving time (DST) mismatch. Unix timestamps are timezone-agnostic - they always represent UTC. If you input a local time but treat it as UTC (or vice versa), you get an offset equal to your timezone's difference from UTC. Always verify whether your source date is in UTC or local time, and set the timezone offset accordingly in this tool.

The Year 2038 problem (Y2K38) occurs because many systems store Unix timestamps as a signed 32-bit integer, which overflows at 2,147,483,647 (2038-01-19 03:14:07 UTC). This tool uses JavaScript's Number type, which is a 64-bit float - safe for integer precision up to 2^53, corresponding to dates roughly 285,000 years in the future. You can safely convert dates well beyond 2038 here.

A negative timestamp represents a date before the Unix epoch (1970-01-01 00:00:00 UTC). For example, 1969-12-31 23:59:59 UTC corresponds to timestamp −1. This tool fully supports negative timestamps for historical date conversions. Note that some downstream systems (particularly unsigned 32-bit storage) cannot represent negative values.

No, and by design. POSIX time (Unix time) explicitly does not count leap seconds. Every POSIX day is exactly 86,400 seconds. The 27 leap seconds inserted since 1972 are absorbed by the operating system's clock adjustment (typically via NTP smearing). This means a Unix timestamp is technically ambiguous during a leap second insertion, but this ambiguity is standard behavior across all POSIX-compliant systems.

Traditional Unix timestamps use seconds precision (10 digits as of 2024, e.g., 1,700,000,000). JavaScript's Date.getTime() returns milliseconds (13 digits, e.g., 1,700,000,000,000). Many APIs and databases use one or the other. If your 13-digit timestamp produces a date in the year 55,000+, you are likely passing milliseconds to a seconds parser. This tool outputs both formats to prevent this common error.

Yes. Enter any valid ISO 8601 string (e.g., 2024-03-15T14:30:00Z or 2024-03-15T14:30:00+05:30) into the text input field and the tool will parse it. The trailing Z indicates UTC; a numeric offset like +05:30 is applied automatically. If no timezone indicator is present, the string is treated as local time per the ECMAScript specification.