Unixタイムスタンプ 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);

パイソン

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

クイックリファレンステーブル

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) その代わり。
• 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.

あなたも好きかもしれません

新しい

UUID vs ULID vs CUID: Which Unique ID Should You Use?

続きを読む "

掲載日 4月 19, 2026

新しい

CSS グラデーション： 書くこととデバッグするための推測なし

続きを読む "

掲載日 2026年4月17日

新しい

JWTトークン： デコード、検証、および一般的な間違いを避ける

続きを読む "

掲載日 4月 16, 2026

新しい

開発者向けの正規表現クイックリファレンスガイド: 模様の覚え書きに役立つパターン

続きを読む "

掲載日 4月 15日、2026年