Your files stay with you.
Guide · 3 min read

Unix Timestamps Explained: Seconds, Milliseconds and Time Zones

What a Unix timestamp is, why some are 10 digits and others 13, how time zones and daylight saving fit in, and how to avoid the most common date bugs.

Updated

Databases, log files, APIs and JWTs often store time as a single large number, such as 1793318400. That number is a Unix timestamp. It is one of the simplest ways for computers to agree on a moment in time, but it is also behind a surprising number of bugs.

What the number means

A Unix timestamp counts the seconds that have passed since midnight UTC on 1 January 1970. That starting point is called the Unix epoch, which is why timestamps are also called epoch time. A timestamp of 0 is the epoch itself, 86400 is exactly one day later, and negative numbers are dates before 1970.

The big advantage is that a timestamp is the same everywhere. 1793318400 is one specific instant, whether you are in Tokyo, Toronto or Lagos. There is no time zone and no daylight saving inside the number. Those only appear when you turn it into a date for a person to read.

Seconds or milliseconds?

The classic Unix timestamp is in seconds and, for current dates, has 10 digits. JavaScript, Java and many web APIs use milliseconds instead, which gives 13 digits. Some systems go further and use microseconds (16 digits) or nanoseconds (19 digits).

Mixing them up is the most common timestamp bug. If you read a millisecond value as seconds, you get a date tens of thousands of years in the future. If you read a seconds value as milliseconds, you get a date in January 1970. Whenever a converted date looks absurd, check the number of digits first. The Unix Timestamp Converter detects seconds and milliseconds automatically from the size of the number.

Turning a timestamp into a date

To show a timestamp to a person, a program picks a time zone and applies its rules. The same instant can be displayed as:

  • UTC: 2026-10-30T18:00:00Z. The Z means UTC (sometimes called “Zulu time”).
  • With an offset: 2026-10-30T12:00:00-06:00, the same moment in a zone six hours behind UTC.
  • Local format: “Friday, October 30, 2026, 12:00 PM”, which is friendly but loses the zone unless you add it.

The ISO 8601 format with an explicit offset or Z is the safest way to write a date as text, because it can be read back without guessing.

Time zones and daylight saving

Time zones are not just fixed offsets. A zone such as America/New_York is a set of rules: five hours behind UTC in winter, four in summer, with the change dates set by law and occasionally revised. That is why good software stores the zone name rather than just an offset when the zone matters, for example for a recurring meeting.

Daylight saving creates two awkward cases. When clocks spring forward, an hour of local time never happens, so a local time like 2:30 AM does not exist that day. When clocks fall back, an hour happens twice, so 1:30 AM is ambiguous. Timestamps avoid both problems because they never repeat or skip. The Time Zone Converter uses your browser’s built-in time zone database, so it applies these rules correctly for any date.

Best practices

  • Store in UTC. Save timestamps or UTC dates in databases and logs. Convert to local time only when you display them.
  • Be explicit about units. Name fields createdAtMs or expiresAtSec, or document the unit clearly.
  • Keep the zone name for future events. A meeting at “9:00 in Berlin next March” should be stored as a local time plus Europe/Berlin, because the offset may change before then.
  • Don’t do date maths by hand. Adding 86,400 seconds is not always “the same time tomorrow” across a daylight saving change. Use a date library for calendar arithmetic.

The year 2038 problem

Older systems store timestamps as a signed 32-bit integer, which can count only up to 2,147,483,647 seconds. That limit is reached at 03:14:07 UTC on 19 January 2038, after which the number wraps around to a date in 1901. Modern operating systems and languages use 64-bit values, which last for billions of years, but old embedded devices and file formats may still be affected. If you maintain such a system, test it with dates after 2038.

Where you will meet timestamps

  • The iat and exp claims in a JSON Web Token.
  • Log files and monitoring tools.
  • File modification times and database columns.
  • API fields such as created or updated_at.

Whenever you find one, paste it into the Unix Timestamp Converter to see it as a date in UTC and in your own time zone.

Tools in this guide

More guides