Unix Timestamps Explained: Seconds, Milliseconds and 2038

Dieser Inhalt ist auf Englisch.

Unix timestamps are one of the simplest ways to store a point in time, and you will meet them in logs, databases, APIs and web code. This guide explains what they count, how to tell seconds from milliseconds, how to convert them both ways, and why the year 2038 matters.

Von Valtrinity. Aktualisiert am 18. Oktober 2026.

What a Unix timestamp counts

A Unix timestamp is the number of seconds that have passed since 1 January 1970 at 00:00:00 UTC, a moment known as the Unix epoch. Because it is a single number, it is easy to store, sort and compare, and it does not depend on any time zone. Two timestamps can be subtracted to find the gap between events in seconds.

Leap seconds are not counted separately, so each day is treated as exactly 86,400 seconds. This keeps the arithmetic simple, although it means the count drifts slightly from astronomical time. For everyday software, the difference never matters.

Seconds or milliseconds?

The original Unix convention counts seconds, but many modern systems count milliseconds instead. JavaScript's Date.now and Java's System.currentTimeMillis both return milliseconds, so their values are about a thousand times larger. A quick check is the digit count: a current timestamp in seconds has ten digits, while the same moment in milliseconds has thirteen.

• 10 digits: seconds, valid until 2286
• 13 digits: milliseconds, the common format in JavaScript and Java
• 16 digits: microseconds, used by some databases and logging tools
• 19 digits: nanoseconds, used by some languages and tracing systems

Converting timestamps to dates

To convert a seconds-based timestamp in JavaScript, multiply by 1000, pass the result to the Date constructor, then call toISOString for a standard UTC string. For example, new Date(1700000000 * 1000).toISOString() returns 2023-11-14T22:13:20.000Z. Going the other way, Math.floor(Date.now() / 1000) gives the current time in whole seconds.

In Python, datetime.datetime.fromtimestamp(1700000000, tz=datetime.timezone.utc) returns the same moment as a timezone-aware value, and int(time.time()) gives the current timestamp in seconds. In a spreadsheet, the formula =A1/86400+DATE(1970,1,1) turns a seconds-based value in cell A1 into a date and time, provided the cell is formatted to show both. The timestamp-converter tool does the same job without any code.

Time zones: timestamps are always UTC

A Unix timestamp carries no time zone. It is an absolute moment, and only when you display it as local time does a zone come into play. Problems appear when code adds an offset twice, or when a string such as 2026-10-15 09:00 is parsed without a zone and assumed to be UTC on one server and local time on another. Store timestamps in UTC and convert them at the edges of your system.

Most libraries output ISO 8601 strings with a trailing Z, which means UTC. If you see a string without that letter or an offset, treat the zone as unknown until you confirm it.

Converting dates to timestamps

To go from a date to a timestamp, parse the date with an explicit zone. In JavaScript, Date.parse('2026-10-15T09:00:00Z') returns milliseconds, so divide by 1000 for seconds. Leaving off the Z makes date-and-time strings use local time, which shifts the result by your offset. In SQL, UNIX_TIMESTAMP in MySQL and EXTRACT(EPOCH FROM ...) in PostgreSQL perform the same job.

The 2038 problem

Many older systems stored timestamps as signed 32-bit integers, which can hold values up to 2,147,483,647. That number corresponds to 19 January 2038 at 03:14:07 UTC. One second later the counter wraps to a large negative number, which systems read as a date in December 1901. Software that performed date arithmetic could then fail in confusing ways.

Modern 64-bit systems use a range so large that it will not run out for roughly 292 billion years, so new code is generally in good shape on this point. The risk lies in embedded equipment, legacy databases and file formats that still use four-byte time fields. MySQL's TIMESTAMP type, for example, has an upper limit of 19 January 2038, so use DATETIME or a 64-bit alternative for dates beyond that.

Telling seconds from milliseconds in code

When you receive a timestamp of unknown precision, a simple heuristic is to compare its size with a sensible range. A value below 10000000000 is almost certainly seconds for any date between 1970 and 2286, while a larger value is more likely milliseconds. Document the unit in your API, because guessing causes errors such as dates in 1970 or dates tens of thousands of years in the future.

Negative timestamps represent moments before the epoch. Most modern systems handle them correctly, but some older 32-bit libraries do not, so test any date before 1970 that your software must support.

Practical tips for working with timestamps

The timestamp-converter tool on this site converts between seconds, milliseconds and readable dates in either direction, which is handy when you are checking a log line or an API response. Pairing that habit with a few simple conventions prevents most timestamp bugs before they start.

• Store timestamps in UTC, and convert them for display only
• Name fields clearly, for example created_at_ms or created_at_s
• Use one precision consistently across the whole system
• Prefer ISO 8601 strings in APIs that people read directly
• Test edge cases such as the epoch, leap years and daylight saving transitions

In diesem Ratgeber erwähnte Tools

Häufige Fragen