What a Unix timestamp is
A Unix timestamp counts the seconds elapsed since midnight UTC on 1 January 1970, a moment known as the Unix epoch. It is the standard way computers store points in time, because a single integer is unambiguous, sorts correctly, and carries no timezone or formatting baggage.
That last property is the important one. A timestamp is inherently in UTC. It has no timezone, which is exactly why it is used — the timezone is applied when displaying it, not when storing it.
Seconds versus milliseconds
This is the most common source of confusion. Unix timestamps in most languages and databases are in seconds. JavaScript, however, works in milliseconds, as do several other systems.
Mixing them produces obviously wrong results: treating a millisecond value as seconds gives a date around the year 57000, while treating seconds as milliseconds gives a date in January 1970. The auto-detect option here distinguishes them by magnitude, since current second-based timestamps are ten digits and millisecond-based ones are thirteen.
The year 2038 problem
Systems storing timestamps in a signed 32-bit integer overflow on 19 January 2038, when the value exceeds the maximum that fits. The counter wraps to a large negative number, placing the date in 1901.
This is a real problem, not a curiosity like the year 2000 concern proved to be. It affects embedded systems, older databases and any code using 32-bit time types. Modern 64-bit systems are unaffected for a period longer than the age of the universe, but legacy hardware in industrial and infrastructure settings remains genuinely exposed.
Why developers store timestamps
Storing a formatted date string invites trouble: it embeds a timezone assumption, sorts incorrectly as text in some formats, and varies by locale. A timestamp avoids all three. Arithmetic is trivial — the difference between two moments is subtraction — and conversion to any timezone happens at display time.
The practice worth following is storing UTC always and converting only when rendering to a user. Storing local times leads to ambiguity twice a year when clocks go back, where the same wall-clock hour occurs twice.
Leap seconds
Unix time deliberately ignores leap seconds, pretending every day contains exactly 86,400 seconds. This means it is not a true count of elapsed physical seconds since 1970, and is a known limitation of the format rather than an error. For almost all applications the difference is irrelevant.
Converted locally
All conversion happens in your browser using its own date functions. Nothing is transmitted.
Frequently Asked Questions
Is a Unix timestamp in seconds or milliseconds?
Traditionally seconds, but JavaScript and some other systems use milliseconds. Ten digits indicates seconds; thirteen indicates milliseconds.
Does a timestamp have a timezone?
No. It is always UTC by definition. Timezone is applied only when formatting it for display.
What is the year 2038 problem?
Systems storing time in a signed 32-bit integer overflow on 19 January 2038 and wrap to 1901. It affects embedded and legacy systems, not modern 64-bit ones.
Why store timestamps instead of formatted dates?
They are unambiguous, sort correctly, make arithmetic trivial, and carry no timezone or locale assumptions.
Does Unix time account for leap seconds?
No. It assumes every day has exactly 86,400 seconds, which is a deliberate simplification in the format.