One number, any time zone
A Unix timestamp carries no time zone and no calendar. 1780511400 is June 3, 2026 at 18:30:00 UTC, a Wednesday. The same second reads 14:30:00 in New York (UTC-4) and 03:30:00 on June 4, 2026 in Tokyo (UTC+9). The number stays the same everywhere. Only the clock you show it on changes, so store the timestamp and convert at the edge.
Zero is the epoch: January 1, 1970, a Thursday. Counting forward, 1700000000 fell on November 14, 2023 and 2000000000 arrives on May 18, 2033.
POSIX counts every day as the same length, so leap seconds never show up in a timestamp. That keeps date math simple. The cost is that a subtraction across a leap second misses that real second.
Seconds or milliseconds
Unix tools, databases and many APIs count seconds. JavaScript counts milliseconds: Date.now() returns the milliseconds since the epoch. The moment above is 1780511400 in seconds and 1780511400000 in milliseconds. A seconds timestamp has 10 digits today and a milliseconds one has 13, so counting digits is the quick check.
Mix them up and the date is off by a factor of 1000. Read that milliseconds value as seconds and you land in the year 58392. The seconds or milliseconds guide covers the edge cases.
Where the count runs out
Old systems stored the count in a signed 32-bit integer, which tops out at 2,147,483,647. That's 03:14:07 UTC on January 19, 2038. One second later the value wraps to -2,147,483,648, which is December 13, 1901. This is the year 2038 problem. It's a real risk for embedded devices, old file formats and narrow database columns, and no issue for a 64-bit count, which reaches about 292 billion years either way. Check the column type, not just the language.
The same minus sign explains dates before 1970. -14182940 is July 20, 1969. The number is valid, but code that assumes a timestamp is positive can break on it.
Using timestamps in code
Store UTC timestamps and format them for the reader's zone at display time. Use them for date math, since subtracting two gives a duration in seconds with no parsing. For text that people read, an ISO 8601 string like 2026-06-03T18:30:00Z is the usual choice, at 20 characters against 10 digits for the integer. To time how long something took, use a monotonic clock, because the wall clock can jump when it's synced.
You'll meet timestamps in login tokens too: JWT claims like exp and iat are counted in seconds. The JWT claims guide shows real values.