Programmingbeginner7 min read

Unix Timestamps Explained

Understand what Unix timestamps are, why they're always UTC, the difference between seconds and milliseconds, the Year 2038 problem, and how to work with them in code.

What is a Unix Timestamp?

A Unix timestamp (also called POSIX time or epoch time) is the number of seconds that have elapsed since the Unix Epoch: January 1, 1970, 00:00:00 UTC. It provides a single, unambiguous number to represent any point in time.

For example, `1717200000` represents May 31, 2024 at 20:00:00 UTC. Every programming language, database, and operating system understands this format, making it the universal language of time in computing.

Seconds, Milliseconds, and Nanoseconds

The Unix timestamp standard uses seconds, but many environments use finer granularity:

Seconds (10 digits, e.g. `1717200000`) — Unix/Linux syscalls, most databases, HTTP headers (e.g. JWT `exp` claims)
Milliseconds (13 digits, e.g. `1717200000000`) — JavaScript's `Date.now()`, Java's `System.currentTimeMillis()`, most REST APIs
Microseconds (16 digits) — PostgreSQL's `EXTRACT(EPOCH FROM timestamp)` returns fractional seconds; some logging systems
Nanoseconds (19 digits) — Go's `time.Now().UnixNano()`, Rust's `SystemTime`

When you receive an unknown timestamp, count the digits: 10 → seconds, 13 → milliseconds, 16 → microseconds, 19 → nanoseconds.

Timestamps Are Always UTC

Unix timestamps have no concept of timezone or Daylight Saving Time — they always represent UTC. This is one of their greatest strengths: `1717200000` means exactly the same instant everywhere on Earth.

Timezone conversion happens only at display time, when you format the timestamp for human consumption. This separation is what prevents bugs like: - Storing "the same" time in two different timezones and getting different values - DST transitions causing events to appear duplicated or missing - Comparison failures between timestamps from different regions

Always store and transmit timestamps in UTC (as Unix timestamps or ISO 8601 with Z), and convert to local time only in the UI layer.

The Year 2038 Problem

Many legacy systems store Unix timestamps as a 32-bit signed integer, which can hold values up to `2,147,483,647`. That value corresponds to January 19, 2038 at 03:14:07 UTC — after which the counter overflows to a large negative number, representing December 13, 1901.

Affected systems include: older 32-bit Linux kernels, some embedded devices (routers, IoT sensors), older versions of MySQL's TIMESTAMP type, and some PHP time functions.

64-bit integers can store timestamps until the year 292,277,026,596 — effectively forever. Most modern systems use 64-bit, but embedded and legacy systems are still being updated.

Working with Timestamps in Code

Common operations across languages:

// JavaScript
const nowMs  = Date.now();                // milliseconds
const nowSec = Math.floor(Date.now() / 1000); // seconds
const date   = new Date(1717200000 * 1000);   // from seconds
const iso    = date.toISOString();            // '2024-05-31T20:00:00.000Z'

# Python
import time, datetime
now_sec = int(time.time())
dt = datetime.datetime.fromtimestamp(1717200000, tz=datetime.timezone.utc)

// Go
import "time"
nowSec := time.Now().Unix()       // int64 seconds
nowMs  := time.Now().UnixMilli()  // int64 milliseconds
t      := time.Unix(1717200000, 0).UTC()

Converting Timestamps with DevForge

The DevForge Unix Timestamp Converter is ideal for debugging time-related issues in API responses and log files. Paste any numeric timestamp (seconds or milliseconds) to instantly see the corresponding human-readable date and time with timezone support. Or enter a date to get the epoch value — useful when constructing query parameters or JWT expiry claims by hand.

Try it on DevForge

Free online tools related to this tutorial — no signup required.

Unix Timestamp Converter

Convert timestamps

CLK

Cron Expression Generator

Build cron expressions