Timestamp

[01] What a Unix timestamp is

A Unix timestamp is the number of seconds since 00:00:00 UTC on 1 January 1970 (the "Unix epoch"). It is a single integer that uniquely identifies a moment in time, independent of timezone. 1740441600 means the same instant whether you are in New York, Dubai, or Tokyo - what changes is how that instant is displayed in the local clock.

Most languages and runtimes can convert a timestamp to a local date in one line: new Date(1740441600 * 1000) in JavaScript, datetime.fromtimestamp(1740441600) in Python, time.Unix(1740441600, 0) in Go.

[02] Seconds vs milliseconds

Unix timestamps come in two common precisions:

• Seconds (10 digits, e.g. 1740441600) - the original Unix convention. Used by databases, log files, most APIs, and the date command on Linux/macOS.
• Milliseconds (13 digits, e.g. 1740441600000) - the JavaScript native format (Date.now()). Used by browsers, Node.js, and many web APIs.

The 1000x difference is a frequent bug source: a millisecond timestamp passed to a "seconds" parser becomes a date roughly 31,000 years in the future. The auto-detect on this tool checks digit length to pick the right interpretation.

[03] Timezones, briefly

The timestamp itself has no timezone - it is always UTC seconds. Display, on the other hand, is always in some timezone. The same timestamp renders as different wall-clock times depending on where you look at it. That is why this tool offers a timezone selector: the underlying integer never changes, only the formatted output. Daylight saving shifts only affect display; the stored timestamp is unaffected.

For storage, always store as UTC (or as the timestamp integer). Convert to local time only at the display layer. Storing local time without a timezone tag is the classic "spring-forward / fall-back" bug source.

[04] Common pitfalls

• The Year 2038 problem. 32-bit signed Unix timestamps overflow on 19 January 2038. Modern systems use 64-bit timestamps; legacy embedded systems may not. Check before you bet on it.
• Leap seconds. POSIX timestamps ignore leap seconds, so a timestamp is not perfectly aligned with UTC during a leap. For most software this is invisible. For high-precision systems (GPS, finance, telecoms) it matters.
• RFC 2822 vs ISO 8601. Email headers use RFC 2822 (Tue, 25 Feb 2026 00:00:00 +0000); APIs prefer ISO 8601 (2026-02-25T00:00:00Z). Both encode the same moment; the formatter you pick depends on the consumer.
• Negative timestamps. Dates before 1970 are valid - they're negative integers. Some parsers reject them, so test your code path with a pre-epoch date if your domain needs it.