Unix Timestamps and Timezones Without the Headaches
Dates and times are where a surprising number of bugs live: an event shows up an hour off, a “today” filter misses records, a sort order looks random. Almost all of it traces back to one confusion: mixing up the instant something happened with how that instant is displayed. The Unix timestamp is the tool that keeps the two separate, and once the model clicks, the headaches mostly stop.
What a Unix timestamp is
A Unix timestamp is a single number: the count of seconds since midnight UTC on 1 January 1970, a reference moment called the epoch. That is the whole definition. Because it is one number measured in UTC, it pins down one exact instant in time anywhere on Earth, with no ambiguity about which timezone or daylight-saving rule applies.
The golden rule: store and compute in UTC timestamps, convert to local time only for display. Follow it and most timezone bugs simply cannot happen.
Why store time this way
A timestamp is just an integer, so comparing, sorting and doing arithmetic on times becomes trivial: later is a bigger number, and the gap between two events is one subtraction. There is no parsing, no locale, no daylight-saving edge case to trip over while you compute. All of that complexity is deferred to the very last step, showing the time to a human. Convert a value either way with a Unix timestamp converter to see the same instant as both a number and a readable date.
Seconds or milliseconds?
This catches everyone eventually. The classic Unix timestamp is in seconds, but plenty of systems, JavaScript most notably, use milliseconds. The two differ by a factor of a thousand, so feeding milliseconds into something expecting seconds lands you in the year 50,000. A quick tell: today a seconds value is about 10 digits, a milliseconds value about 13. Check the digit count before you trust a number.
Timezones are a display concern
A timestamp has no timezone. It is always UTC. The timezone enters the picture only when you render the instant for a person, converting that one UTC moment into their local clock time. So a server in one country and a user in another can agree perfectly on when something happened; they just show it on different clocks. Keep that boundary clear and “off by one hour” bugs largely vanish.
The year 2038 problem, briefly
Older systems stored the timestamp in a signed 32-bit integer, which runs out of room in January 2038 and wraps around to a negative number. Modern systems use 64-bit values, which extend the range far beyond any practical concern. The takeaway for new code is simple: store timestamps as 64-bit and the problem never touches you.
Frequently asked questions
What is a Unix timestamp?
It is the number of seconds that have passed since midnight UTC on 1 January 1970, a moment called the epoch. Because it is a single number in UTC, it represents one exact instant with no timezone ambiguity.
Is a Unix timestamp in seconds or milliseconds?
Traditionally seconds, but many systems, including JavaScript, use milliseconds. A seconds value is about 10 digits today and a milliseconds value about 13, so the length is a quick way to tell which one you have.
Does a Unix timestamp have a timezone?
No. A timestamp is always in UTC. The timezone only matters when you display it to a person, at which point you convert the single UTC instant into their local time.
What is the year 2038 problem?
Older systems store the timestamp in a signed 32-bit integer, which overflows in January 2038. Modern systems use 64-bit values, which push the limit billions of years away, so new code should store timestamps as 64-bit.