What Is a Unix Timestamp and Why Do Programmers Use It?

A Unix timestamp is the number of seconds since January 1, 1970, at 00:00:00 UTC. It is the universal time format in programming: every database, every log file, every API, and every modern operating system uses it internally. This guide explains what it is, why it exists, and the practical consequences — including the Y2038 problem.

The epoch: January 1, 1970, 00:00:00 UTC

Unix was developed in 1969-1970 at Bell Labs. When the designers needed a way to represent time internally, they chose "seconds since the system was born" as the simplest possible representation. The starting point — January 1, 1970, at midnight UTC — is called the Unix epoch.

Some sources say the choice of 1970-01-01 was arbitrary; others say it was chosen because it was the start of the decade the system was built. In any case, it is the convention, and every Unix timestamp is relative to it.

Seconds vs milliseconds

The original Unix timestamp counted seconds. Most modern systems count milliseconds. JavaScript's Date.now() returns milliseconds. Java's System.currentTimeMillis() returns milliseconds. Python's time.time() returns seconds (with sub-second precision as a float).

The convention varies. The reliable check: the magnitude. A current Unix timestamp in 2026 is around 1.79 billion in seconds, or 1.79 trillion in milliseconds. A timestamp of 1780000000 is from June 2026 in seconds; a timestamp of 1780000000000 is from the year 2026 in milliseconds. The mistake of mixing the two is one of the most common bugs in date-handling code.

Why use a number instead of a date?

The reasons Unix timestamps are everywhere:

Timezone independence

A Unix timestamp is a count of seconds since a specific moment. That moment is the same in every timezone — it is just a count. A human-readable date like "2026-08-15 14:30:00" requires a timezone to be unambiguous (is that UTC? EST? IST?). A Unix timestamp is unambiguous without a timezone.

Comparison is trivial

To check if one timestamp is before or after another, just compare the numbers. timestamp_a < timestamp_b works in every language. To do the same with human-readable dates, you have to parse them first.

Storage is fixed-size

A Unix timestamp is a 32-bit or 64-bit integer. It is the same size in any database. A human-readable date is variable length (the year alone can be 1-4 digits, the month always 2, the day always 2, plus separators and timezone info).

Arithmetic is trivial

To add 5 minutes to a timestamp: timestamp + 300. To compute the difference: timestamp_a - timestamp_b. With human-readable dates, you have to call a date library for every operation.

Where you see Unix timestamps

Almost everywhere in software:

• File systems — every file's mtime, atime, and ctime are Unix timestamps.
• Databases — most database engines have a native "timestamp" or "datetime" type stored as Unix seconds or milliseconds.
• Logs — the leading number in most log lines is a Unix timestamp.
• APIs — REST APIs return timestamps in JSON; the choice is usually seconds (X/Twitter, Stripe) or milliseconds (most JavaScript APIs).
• Git — every commit has a Unix timestamp in its metadata.
• HTTP — the Date header is a date string, but internal calculations use timestamps.

How to convert

The Uttir Unix Timestamp Converter converts to and from human-readable dates in your browser. You can also do it in any programming language:

JavaScript

// Current timestamp in milliseconds
Date.now()  // 1755264600000

// Convert timestamp to date
new Date(1755264600 * 1000)  // 2025-08-15T...
new Date(1755264600000)       // 2025-08-15T...

// Convert date to timestamp
Math.floor(new Date('2025-08-15').getTime() / 1000)  // 1755216000

Python

import time
import datetime

# Current timestamp in seconds
time.time()  # 1755264600.0

# Timestamp to date
datetime.datetime.fromtimestamp(1755264600)  # 2025-08-15 ...

# Date to timestamp
datetime.datetime(2025, 8, 15).timestamp()  # 1755216000.0

SQL

-- Convert timestamp to date (PostgreSQL)
SELECT to_timestamp(1755264600);  -- 2025-08-15 ...

-- Current timestamp
SELECT EXTRACT(EPOCH FROM NOW());  -- 1755264600.0

The Y2038 problem

On January 19, 2038, at 03:14:07 UTC, a 32-bit signed Unix timestamp will overflow. A 32-bit signed integer holds values from -2,147,483,648 to 2,147,483,647. The overflow value is 2,147,483,647 seconds after the epoch, which is January 19, 2038, 03:14:07 UTC. After that moment, a 32-bit timestamp will wrap around to a negative number — interpreting it as December 13, 1901.

This will break:

• Any 32-bit system storing time as seconds (most embedded systems, some older servers, many IoT devices).
• Any file format that uses 32-bit time (some image and document formats).
• Any database column typed as 32-bit integer.

It will NOT break:

• 64-bit systems (every modern phone, laptop, and server is 64-bit).
• Systems that store milliseconds (even 32-bit, milliseconds is good until the year 500,000,000).
• File formats that already use 64-bit time (most modern formats).

The fix is straightforward: migrate to 64-bit time. Most operating systems and libraries have done this. The remaining risk is the long tail of embedded systems and old file formats. The Y2038 problem is a real issue, but it is not a civilization-ending event — more like Y2K, which was a lot of work but not a disaster.

Common pitfalls

Mixing seconds and milliseconds

The number one timestamp bug. If you store milliseconds and the API returns seconds, every comparison is off by 1000x. The fix: pick one convention and stick to it. Most modern systems use milliseconds because JavaScript forces the issue. If you have a system that uses seconds, wrap every conversion in a helper function with a clear name like toUnixSeconds() or toUnixMillis().

Timezone confusion

A Unix timestamp is timezone-independent — it represents a single moment. But when you convert it to a human-readable date, the result depends on the timezone of the viewer. A timestamp of 1755264600 is "2025-08-15 14:30:00" in UTC, "2025-08-15 10:30:00" in EDT, and "2025-08-15 20:00:00" in IST. Always store the timestamp in UTC, and convert to the user's timezone at display time.

Leap seconds

Leap seconds are occasional one-second adjustments made to UTC to account for the Earth's slowing rotation. Unix timestamps do not count leap seconds. Most days are 86400 seconds long; a day with a leap second is 86401 seconds. Most systems do not handle this and the difference is negligible in practice. If you need true precision, use a different time format (TAI, for example).

Local time in the database

Storing "2025-08-15 14:30:00" in a database without a timezone is a recipe for bugs. The database has no way to know which timezone you meant. Always store either a Unix timestamp (UTC by definition) or a "timestamp with time zone" type. Never store a timestamp without a timezone.

What to use instead

For most modern systems, Unix timestamps are the right answer. For specialized cases:

• ISO 8601 strings — 2025-08-15T14:30:00Z. Human-readable, sortable, timezone-explicit. Good for APIs, log files, and inter-system communication. The Uttir Date Formatter converts between ISO 8601 and other formats.
• RFC 3339 — a profile of ISO 8601 used in HTTP, Atom, and other protocols. Same as ISO 8601 with a few constraints.
• Windows FILETIME — 100-nanosecond intervals since 1601-01-01. The Windows equivalent of Unix timestamps. Not interoperable.
• Java's Instant — milliseconds since 1970-01-01, with nanosecond precision. Same epoch as Unix, finer resolution.

For most purposes, Unix timestamp in milliseconds is the right choice. Convert at the edges of the system (when reading from an API, when displaying to a user) and store the integer in the middle.

Bottom line

The Unix timestamp is the universal language of time in software. Seconds since 1970, no timezone, easy to compare, easy to store. The Y2038 problem is real but manageable — 64-bit systems and millisecond timestamps are the fix. The Uttir Unix Timestamp Converter converts to and from human-readable dates in your browser.