One number.
One moment.
Every time zone.

02 · Exactly what it counts

⏱️ The definition, precisely

Unix time counts seconds since 1970-01-01 00:00:00 UTC, with one important simplification: every day is treated as exactly 86,400 seconds. Leap seconds — the occasional extra second added to UTC to keep it aligned with the Earth's rotation — are simply not counted.

📌 Handy reference points

03 · The most common bug

🔢 Seconds vs milliseconds

Classic Unix tools, C, PHP, Python's time.time(), most SQL functions and JWT claims like exp use seconds. JavaScript's Date, Java's System.currentTimeMillis() and many logging and analytics systems use milliseconds. Mix them up and you get dates in January 1970 or tens of thousands of years in the future.

04 · Where local time fits in

🌍 Time zones & ISO 8601

A Unix timestamp has no time zone. It identifies a single instant that is the same everywhere on Earth. Time zones only appear when you display that instant: 1718352000 is 08:00 UTC — which is 09:00 in London (British Summer Time), 13:30 in India (UTC+05:30) and 04:00 in New York (UTC−04:00 in June).

1. 💾 Store the instant

   Save timestamps in UTC — as a Unix number or a UTC date-time column. Never store "local time" without its offset.

2. 🔁 Compute in UTC

   Durations, comparisons and sorting all work directly on the number. Daylight-saving changes can't break them.

3. 🖥️ Convert at the edge

   Turn it into local time only when showing it to a person, using their time zone.

🆚 Unix timestamp or ISO 8601?

ISO 8601 (and its stricter internet profile, RFC 3339) is the standard text format for dates: 2024-06-14T08:00:00Z, or with an offset, 2024-06-14T13:30:00+05:30. Both lines describe the same moment as 1718352000.

A common, sensible split: use ISO 8601 with Z in public JSON APIs (see What is JSON?) and Unix numbers internally, where compactness and arithmetic matter.

05 · A deadline with a date

💥 The Year 2038 problem

Many older systems store Unix time in a signed 32-bit integer. The largest value that type can hold is 2147483647 — which is 2038-01-19 03:14:07 UTC. One second later, the value overflows and wraps round to -2147483648, which those systems read as 1901-12-13 20:45:52 UTC.

Modern 64-bit operating systems, languages and databases already use 64-bit time, so most application code is fine. The risk sits in the places people forget:

• Embedded devices and firmware with 32-bit clocks that will still be in service in 2038.
• Database columns — MySQL's TIMESTAMP type, for example, has a range that ends at 2038-01-19 03:14:07 UTC. DATETIME or a 64-bit integer column avoids it.
• File formats and protocols that define a 32-bit time field.
• Your own code that casts a timestamp to a 32-bit int. Use long / int64.

06 · In your code

🛠️ Getting & converting timestamps

Date.now();                                  // milliseconds: 1718352000000
Math.floor(Date.now() / 1000);               // seconds:      1718352000

new Date(1718352000 * 1000).toISOString();   // "2024-06-14T08:00:00.000Z"
Date.parse("2024-06-14T08:00:00Z") / 1000;    // 1718352000

long secs = DateTimeOffset.UtcNow.ToUnixTimeSeconds();
long ms   = DateTimeOffset.UtcNow.ToUnixTimeMilliseconds();

DateTimeOffset when = DateTimeOffset.FromUnixTimeSeconds(1718352000);
// 2024-06-14 08:00:00 +00:00

var ist = TimeZoneInfo.FindSystemTimeZoneById("Asia/Kolkata");
DateTimeOffset local = TimeZoneInfo.ConvertTime(when, ist);   // 13:30 +05:30

import time
from datetime import datetime, timezone

int(time.time())                                        # seconds, now
datetime.fromtimestamp(1718352000, tz=timezone.utc)     # 2024-06-14 08:00:00+00:00
datetime(2024, 6, 14, 8, tzinfo=timezone.utc).timestamp()   # 1718352000.0

# ⚠️ a naive datetime (no tzinfo) is treated as *local* time by .timestamp()

-- PostgreSQL
SELECT extract(epoch FROM now());            -- now, as seconds
SELECT to_timestamp(1718352000);             -- → timestamptz

-- MySQL
SELECT UNIX_TIMESTAMP();
SELECT FROM_UNIXTIME(1718352000);            -- shown in the session time zone

-- SQL Server
SELECT DATEDIFF_BIG(SECOND, '1970-01-01', SYSUTCDATETIME());
SELECT DATEADD(SECOND, 1718352000, '1970-01-01');

-- SQLite
SELECT strftime('%s', 'now');
SELECT datetime(1718352000, 'unixepoch');

date +%s                            # seconds, now
date +%s%3N                         # milliseconds (GNU date)

date -u -d @1718352000                # → date, GNU/Linux
date -u -r 1718352000               # → date, macOS/BSD
date -u -d "2024-06-14T08:00:00Z" +%s   # date → seconds (GNU)