Unix Timestamp Converter

What is a Unix timestamp?

A Unix timestamp (also called epoch time) is the number of seconds since 1 January 1970 at midnight UTC. Because it’s a single number with no timezone attached, it’s the standard way computers store and exchange moments in time — you’ll see it in APIs, databases and log files. This tool auto-detects whether your number is in seconds or milliseconds (JavaScript uses milliseconds, which are 1000× larger) and shows the date in both your local time and UTC.

Why epoch time exists

A Unix timestamp is the number of seconds since 1 January 1970, 00:00:00 UTC. Its virtue is that it is a single integer with no timezone, no locale and no formatting: two timestamps can be compared or subtracted with plain arithmetic, and no parser can misread it. Every ambiguity in date handling comes from the human-readable layer, which is exactly what a timestamp discards.

Seconds or milliseconds?

Unix tools and most APIs use seconds; JavaScript’s Date.now() uses milliseconds. Mixing them produces dates in 1970 (divided by 1,000 too often) or the year 50000+ (multiplied when it should not be). A quick check: a current timestamp in seconds is 10 digits, in milliseconds 13.

Leap seconds and the smooth clock

Unix time pretends every day has exactly 86,400 seconds. Real solar time does not cooperate, so leap seconds are inserted occasionally — and rather than count them, Unix time repeats or skips a value. Google-style “leap smearing” spreads the correction over hours instead. The practical takeaway: timestamps are excellent for ordering events but not a metrology-grade measure of elapsed physical time.

The 2038 problem

A signed 32-bit integer overflows at 03:14:07 UTC on 19 January 2038, wrapping to 1901. Modern systems use 64-bit time, which pushes the limit past the lifetime of the Sun, but 32-bit fields still lurk in embedded firmware, legacy databases and file formats. If you store epoch values, store them 64-bit.

Storing time properly

• Store UTC, display local. Convert at the edge, never in the database.
• Keep the IANA timezone name (Europe/Lisbon) for future events, not a fixed offset — offsets change when daylight-saving rules change.
• Use ISO 8601 (2026-08-01T14:30:00Z) for interchange between systems; it sorts lexicographically and is unambiguous.
• Beware the fixed offset trap. A meeting stored as UTC+1 will be wrong after the clocks change; the zone name survives it.