Convert Unix timestamps to human-readable dates or dates to timestamps. See UTC, local, ISO 8601, and RFC 2822 formats with copy buttons and live relative time.
1777059803Updates every second
A Unix timestamp is the number of seconds elapsed since January 1, 1970 00:00:00 UTC — the Unix epoch. It is widely used in programming, databases, and APIs because it is timezone-independent, monotonically increasing, and trivially comparable. A timestamp of 0 represents the epoch itself; 1704067200 represents 2024-01-01 00:00:00 UTC. Millisecond variants (13 digits) are common in JavaScript and Java — divide by 1,000 to get the standard seconds-based value.
Use timestamps when storing event times in databases, scheduling cron jobs, or debugging API responses. The relative time display (e.g., "2 hours ago" or "in 3 days") helps you quickly understand when an event occurred or will occur.
The Unix epoch (January 1, 1970 00:00:00 UTC) serves as the universal reference point for time in computing. Unix timestamps count the number of seconds from that moment, making them timezone-agnostic and trivially comparable. A timestamp of 0 represents the epoch itself, while 1704067200 represents January 1, 2024 00:00:00 UTC.
Millisecond timestamps (13 digits instead of 10) are common in JavaScript and Java. If your timestamp looks unusually large, it may be in milliseconds — divide by 1,000 to get the standard seconds-based value. Some systems also use microsecond or nanosecond precision for high-frequency event logging.
Always store timestamps in UTC to avoid ambiguity. Convert to the user's local timezone only at the display layer. Be aware of daylight saving time transitions, which can cause the same local time to map to two different UTC values or skip an hour entirely. Libraries like date-fns-tz and the native Intl.DateTimeFormat API help with reliable timezone conversions.
Systems that store Unix timestamps as 32-bit signed integers will overflow on January 19, 2038 at 03:14:08 UTC — the last second representable is 2,147,483,647. After that, the counter wraps to a negative number, interpreted as December 13, 1901. Modern 64-bit platforms (all mainstream OSes since the mid-2010s) are unaffected and extend the range to roughly ±292 billion years.
If your timestamp has 13 digits (e.g., 1704067200000), it is in milliseconds. Divide by 1,000 to get the standard seconds-based Unix timestamp before converting. JavaScript's Date.now() returns milliseconds; Python's time.time() returns seconds; Java's System.currentTimeMillis() returns milliseconds. Always confirm units before passing values between languages.
Yes for dates from 1970 onward. Dates before the Unix epoch are represented as negative timestamps (e.g., -86400 = 1969-12-31 00:00 UTC) and are supported by most modern platforms including JavaScript's Date object. Note: historical calendar changes — the Julian-to-Gregorian transition of 1582 and various national adoptions — are outside the scope of Unix time.
Almost always a timezone issue. Unix timestamps are timezone-agnostic (they always represent the number of seconds since the UTC epoch), but the <em>display</em> depends on the viewer's timezone. A timestamp rendered in "local" on your machine and "UTC" on a server will look different. Store in UTC; convert only at the display layer.
Work in UTC for storage and arithmetic; convert to local only for display. DST transitions create two real-world problems: (1) in spring, 02:30 local does not exist in DST-observing timezones (skipped hour); (2) in fall, 01:30 local happens twice. Libraries like date-fns-tz, Luxon, and Python's zoneinfo resolve both cases safely. Manual offset math without a timezone database will eventually be wrong.
ISO 8601 is the international standard for date/time strings (e.g., 2024-01-01T00:00:00Z). APIs prefer it over Unix timestamps because it is human-readable, includes timezone context, and round-trips unambiguously across languages. Postgres, MySQL, MongoDB, and most JSON APIs accept ISO 8601 natively. Use it when storing in text columns or sending in JSON; use Unix seconds when you need a compact numeric representation for indexing or bandwidth.
RFC 2822 is the date format used in email headers (e.g., "Mon, 01 Jan 2024 00:00:00 +0000"). It is less machine-friendly than ISO 8601 but remains standard in email protocols. Most JSON APIs and modern applications use ISO 8601. The converter outputs both so you can copy the right one for your context.