What is a Unix timestamp?

A Unix timestamp is the number of seconds (or milliseconds) that have elapsed since January 1, 1970, 00:00:00 UTC. It is a universal, timezone-independent way to represent a specific moment in time.

How do I convert a Unix timestamp to a readable date in JavaScript?

Multiply the timestamp by 1000 (to convert seconds to milliseconds), then pass it to the Date constructor: new Date(timestamp * 1000). Call .toISOString() or .toLocaleString() to format it.

Why does my Unix timestamp show 1970?

This usually means you are passing milliseconds where seconds are expected, or vice versa. Check whether your timestamp is 10 digits (seconds) or 13 digits (milliseconds) and convert accordingly.

Are Unix timestamps affected by timezones?

No. A Unix timestamp always represents a UTC moment. Timezones only affect how you display or interpret that timestamp in your application layer.

What is the 2038 problem?

Systems that store Unix timestamps as 32-bit signed integers will overflow on January 19, 2038. Modern systems use 64-bit integers, which are safe for billions of years. Legacy embedded systems and older database schemas using INT(11) for timestamps are the main risk.

¿Odias los anuncios? Ir Sin publicidad Hoy 

Marcas de tiempo Unix How to Convert and Why They’re Everywhere

Publicado el Abr 18, 2026

A practical reference for working with Unix timestamps: seconds vs milliseconds, converting in JavaScript, Python, SQL and bash, timezone traps to avoid, and when to use timestamps over ISO 8601 strings.

Unix Timestamps: How to Convert and Why They're Everywhere 1

ANUNCIO · ¿ELIMINAR?

Unix Timestamps: How to Convert and Why They’re Everywhere

A Unix timestamp is the number of seconds elapsed since January 1, 1970, 00:00:00 UTC — also called the Unix epoch. That date wasn’t chosen for any technical reason; it was simply the current year when Unix was being designed. The epoch is always UTC, which means a timestamp like 1712800000 means the same moment everywhere on the planet, regardless of timezone.

Unix timestamps are used everywhere: HTTP headers, JWT tokens, database records, log files, message queues, and API responses. If you’re building or debugging anything that involves time, you’ll hit them constantly. The IO Tools Unix Timestamp Converter is handy for quick lookups, but you also need to know how to handle them in code.

Seconds vs Milliseconds: The Bug That Gets Everyone

The most common timestamp bug in production: mixing up seconds and milliseconds. The Unix standard uses seconds. JavaScript’s Date.now() returns milliseconds. So does Java’s System.currentTimeMillis().

A timestamp of 1712800000 is April 2024. A timestamp of 1712800000000 (milliseconds) is year 56,000-something. If your date math is producing dates decades in the future or displaying 1970-01-01, this is almost always why.

Rule of thumb: if the timestamp has 13 digits, it’s milliseconds. 10 digits, it’s seconds. When in doubt, divide by 1000 and see if the result makes sense.

Converting Unix Timestamps by Language

Here are the patterns you’ll actually use:

JavaScript

// Get current timestamp (milliseconds — divide by 1000 for seconds)
const tsMs = Date.now();           // e.g. 1712800000000
const tsSec = Math.floor(Date.now() / 1000); // e.g. 1712800000

// Convert seconds timestamp to Date object
const ts = 1712800000;
const date = new Date(ts * 1000);  // must multiply by 1000
console.log(date.toISOString());   // "2024-04-11T02:13:20.000Z"

// Convert Date back to Unix timestamp (seconds)
const tsBack = Math.floor(date.getTime() / 1000);

Pitón

from datetime import datetime, timezone

# Get current timestamp (seconds)
import time
ts = int(time.time())  # e.g. 1712800000

# Convert timestamp to datetime (UTC-aware)
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat())  # 2024-04-11T02:13:20+00:00

# Convert local-naive datetime to timestamp (risky — see timezone section)
ts_back = int(dt.timestamp())

SQL (MySQL / MariaDB)

-- Convert timestamp to datetime
SELECT FROM_UNIXTIME(1712800000);
-- Result: 2024-04-11 02:13:20 (server timezone applies here)

-- Get current Unix timestamp
SELECT UNIX_TIMESTAMP();

-- Convert datetime string to timestamp
SELECT UNIX_TIMESTAMP('2024-04-11 02:13:20');

Bash

# Get current timestamp
date +%s

# Convert timestamp to human-readable (GNU date)
date -d @1712800000
# Output: Thu Apr 11 02:13:20 UTC 2024

# macOS (BSD date)
date -r 1712800000

Tabla de Referencia Rápida

Idioma	Get current (seconds)	Timestamp → date	Date → timestamp
JavaScript	`Math.floor(Date.now()/1000)`	`new Date(ts * 1000)`	`Math.floor(d.getTime()/1000)`
Pitón	`int(time.time())`	`datetime.fromtimestamp(ts, tz=timezone.utc)`	`int(dt.timestamp())`
MySQL	`UNIX_TIMESTAMP()`	`FROM_UNIXTIME(ts)`	`UNIX_TIMESTAMP(datetime_str)`
Bash	`date +%s`	`date -d @ts`	`date -d "2024-04-11" +%s`

Timezone Traps

Unix timestamps are always UTC. Always. The number 1712800000 does not have a timezone — it just counts seconds from the epoch. Timezone is a display concern, not a storage concern.

Where developers get burned:

Python’s datetime.fromtimestamp(ts) without tz=timezone.utc — uses the server’s local timezone, silently. Use fromtimestamp(ts, tz=timezone.utc) en cambio.
MySQL’s FROM_UNIXTIME() — converts to the MySQL server’s timezone setting (@@session.time_zone). If your server is in UTC+8, the result shifts by 8 hours.
Storing datetime in MySQL without UTC normalization — if your app server and DB server are in different timezones, every insert/read is a bug waiting to happen.

The pattern that avoids all of this: store Unix timestamps in the database, convert to human-readable format at display time in the app layer, using the user’s preferred timezone.

Timestamps vs ISO 8601 Strings: What to Store

Both are valid storage formats. The tradeoffs:

Unix timestamp (integer): compact, fast for comparisons and arithmetic, no timezone ambiguity, works across every database engine. Downside: not human-readable without a tool.
ISO 8601 string (e.g. 2024-04-11T02:13:20Z): human-readable in the database, self-documenting. Downside: slower for range queries, timezone can be accidentally omitted or wrong.

For most applications: store timestamps as integers. Use ISO 8601 for APIs and logs where human readability matters. If you must store ISO 8601, always include the Z or explicit offset — a bare 2024-04-11 02:13:20 with no timezone is a disaster in distributed systems.

The 2038 Problem

32-bit signed integers can store a maximum value of 2147483647, which corresponds to January 19, 2038, 03:14:07 UTC. Systems that store Unix timestamps in a 32-bit int will overflow at that moment — rolling back to 1901 or crashing.

Should you worry? If you’re writing new code, no — use 64-bit integers. If you’re maintaining legacy C code, embedded firmware, or older MySQL schemas using INT(11) for timestamps, it’s worth auditing. MySQL’s TIMESTAMP type is also affected; DATETIME is not. Modern systems using 64-bit timestamps are safe well into the year 292 billion.

Need to convert timestamps quickly without writing code? The Unix Timestamp Converter on IO Tools handles seconds and milliseconds, shows the UTC and local time side by side, and lets you paste in a date to get the timestamp back.