A long number like 1735689600 is a timestamp. Specifically, it's seconds since January 1, 1970 at midnight UTC. Every computer and database stores time this way because it's a single integer that means exactly one moment — no timezone confusion, no calendar tricks.
Why 1970?
When Unix was designed in the early 1970s, programmers needed a reference point for time. They picked 1970-01-01T00:00:00 UTC as "epoch zero" — recent enough that small numbers represented recent times, arbitrary enough to not privilege any calendar system. The convention stuck, spread through Unix-like systems, and became the global standard for storing timestamps.
How to read one at a glance
A few mental anchors help:
- 1,000,000,000 — Sep 9, 2001. The billionth second of epoch.
- 1,500,000,000 — July 14, 2017.
- 1,700,000,000 — Nov 14, 2023.
- 1,800,000,000 — Jan 15, 2027.
- 2,147,483,647 — Jan 19, 2038. The 32-bit overflow point.
If a timestamp starts with 17, it's roughly 2024–2025. If it starts with 18, it's 2027 or later. Any timestamp with 10 digits is in the "seconds since 1970" format. 13 digits is milliseconds (JavaScript uses this).
Seconds vs milliseconds
Some systems store epoch in seconds, others in milliseconds (multiply by 1000). JavaScript's Date.now() returns milliseconds; most Unix tools and databases return seconds. Mismatching them produces dates 50+ years off. Always check which unit you're working with.
The 2038 bug
32-bit signed integers overflow at 2,147,483,647 — which in epoch seconds is 03:14:07 UTC on 2038-01-19. Old systems still using 32-bit time will wrap to the minimum negative value, sending their clocks back to December 13, 1901. Most modern systems switched to 64-bit epoch years ago; embedded systems and legacy databases haven't all caught up. It's a slow-motion Y2K that developers are still finding and fixing.
Pick a target date + time, get a live countdown in days / hours / minutes / seconds.