Why Unix time counts seconds, not calendar fields

A Unix timestamp is simply a count of seconds elapsed since January 1, 1970 00:00:00 UTC — no year, month, day, or timezone baked into the number itself, just a single integer that grows steadily forward. That design is exactly what makes it so convenient for computers: comparing two timestamps to see which came first, or computing elapsed time between two events, is plain integer subtraction rather than calendar arithmetic across months and leap years. The tradeoff is that a raw timestamp is meaningless to a human without converting it to a specific timezone's calendar representation — the same timestamp is a different clock time depending on where in the world you're reading it, which is exactly why this tool shows Local, UTC, and ISO 8601 side by side rather than picking just one.

The seconds/milliseconds mixup, and why it matters

JavaScript's own `Date` object internally works in milliseconds since epoch, but most other languages and systems (Unix `date`, many APIs, log timestamps) use seconds — a thousand-fold difference that, if missed, either produces a date near 1970 (treating milliseconds as seconds) or a date thousands of years in the future (treating seconds as milliseconds). This is one of the most common timestamp bugs in practice, and it's exactly why this tool makes the unit an explicit choice rather than trying to guess from the number's magnitude — a guess would work most of the time and fail silently and confusingly on the numbers right at the boundary.