Unix Timestamps and Time Zones: Store Time Without Bugs
3 min read4 October 2026By Muhammad Abdullah
Dates and times cause a remarkable share of software bugs: events an hour early, reports missing a day, timestamps in the year 56000. Almost all of them come from mixing up two different things, a moment in time and how that moment is shown in a particular place. Keep those apart and most of the bugs disappear.
What a Unix timestamp is
A Unix timestamp is the number of seconds since 00:00:00 UTC on 1 January 1970. It names a single moment, the same everywhere on Earth. Right now is the same timestamp in Lahore, London and Los Angeles; only the clocks on the wall differ.
1791072000 seconds (10 digits)
1791072000000 milliseconds (13 digits)Seconds or milliseconds
Most systems and databases use seconds. JavaScript uses milliseconds: Date.now() returns a 13-digit number. Mixing them is the most common timestamp bug of all. Treat seconds as milliseconds and you get a date in early 1970; treat milliseconds as seconds and you get a date tens of thousands of years from now.
const seconds = Math.floor(Date.now() / 1000);
const date = new Date(seconds * 1000); // back to a DateStore UTC, convert for display
Store and pass around moments as UTC, as a timestamp or an ISO 8601 string ending in Z. Convert to a local time only at the last step, when showing it to a person, using that person's own time zone.
new Date().toISOString() // "2026-10-04T09:30:00.000Z"
new Intl.DateTimeFormat("en-GB", {
timeZone: "Asia/Karachi",
dateStyle: "medium",
timeStyle: "short",
}).format(new Date());A string like 2026-10-04 14:30 with no zone is ambiguous. Different systems will read it as different moments. Whenever a time is written down, include its offset or use UTC.
Time zones are not fixed offsets
UTC plus 1 is an offset; Europe/London is a time zone, which is UTC plus 0 in winter and UTC plus 1 in summer. Use named zones from the IANA database, such as Asia/Karachi or America/New_York, not fixed offsets, so daylight saving and government rule changes are handled for you.
Daylight saving bugs
- Not every day is 24 hours. Days when clocks change are 23 or 25 hours, so adding 24 hours is not always "the same time tomorrow".
- Some local times never happen, when clocks jump forward, and some happen twice, when they go back.
- For a future event people will attend in person, such as a meeting at 10 am, store the local time with its named zone, because the UTC moment could shift if the zone's rules change before then.
The year 2038
Systems that store timestamps as signed 32-bit seconds run out on 19 January 2038, when the count overflows. Modern systems use 64 bits and are safe, but older databases, file formats and embedded devices are worth checking if their data will look decades ahead.
Common questions
Is a Unix timestamp in UTC?
Yes. It counts seconds since midnight UTC on 1 January 1970, and the same moment has the same timestamp in every time zone.
Why is my date showing as 1970?
A timestamp in seconds was probably read as milliseconds. Multiply it by 1000 before passing it to JavaScript's Date.
Should I store dates in UTC?
For moments that have happened, yes, and convert for display. For future local events, store the local time and its named time zone.