DevKit Tools

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.

Try it as you readUnix Timestamp and Date DebuggerConvert Unix timestamps to readable dates and back, with seconds and milliseconds told apart and every major time zone shown.

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.

text
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.

js
const seconds = Math.floor(Date.now() / 1000);
const date = new Date(seconds * 1000); // back to a Date

Store 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.

js
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.

Tools from this guide

More guides