What is Unix Time?

Overview of Unix Time

Unix Time (also called Epoch Time or POSIX Time) is a standard format for representing time in computing. It counts seconds since 1970-01-01T00:00:00Z (the epoch) using UTC as its base.

Key Points

• Epoch: January 1, 1970 00:00:00 UTC = 0
• Unit: usually seconds (sometimes milliseconds, microseconds, or nanoseconds)
• Time-zone independent: internally based on UTC, converted to local time only when displayed

Epoch, UTC, and Time Zones

Unix Time is always counted in UTC. Local time zones (e.g., JST = UTC+9) are applied only when converting for display.

Common Misunderstandings

• There is no such thing as "Unix Time in JST": it is always UTC seconds; conversion happens at display time.
• Daylight Saving Time (DST) is handled by local time zone rules, not by Unix Time itself.

Representation (Seconds, Milliseconds, Nanoseconds)

Unix Time is a single integer, but its scale can vary by system or language.

Typical Units

• Seconds: 1735689600 (10-digit, current era)
• Milliseconds: common in JavaScript (1735689600000)
• Microseconds / Nanoseconds: used in databases or high-precision timers

Quick Rule of Thumb

• 10 digits = seconds, 13 digits = milliseconds (check your implementation)

Conversion Examples

Conversion between Unix Time and human-readable dates is common in logs, API data, and expiration checks.

Shell (GNU date)

• Now → seconds: `date +%s`
• Seconds → UTC: `date -u -d @1735689600 +"%Y-%m-%dT%H:%M:%SZ"`
• Seconds → JST: `TZ=Asia/Tokyo date -d @1735689600 +"%Y-%m-%d %H:%M:%S %Z"`

Python

• `import time; int(time.time())` # current seconds
• `from datetime import datetime, timezone; datetime.fromtimestamp(1735689600, tz=timezone.utc)`

JavaScript

• `Math.floor(Date.now() / 1000)` // current seconds
• `new Date(1735689600 * 1000).toISOString()` // UTC ISO8601

PHP

• `time()` // current seconds
• `(new DateTime("@1735689600"))->setTimezone(new DateTimeZone("Asia/Tokyo"))->format("Y-m-d H:i:s")`

SQL (MySQL / PostgreSQL)

• MySQL: `FROM_UNIXTIME(1735689600)` / `UNIX_TIMESTAMP(NOW())`
• PostgreSQL: `to_timestamp(1735689600)` / `EXTRACT(EPOCH FROM now())`

Pitfalls (Year 2038, Leap Seconds, Time Zones)

Be aware of these pitfalls when dealing with Unix Time in real-world systems.

Year 2038 Problem (32-bit time_t)

• On 2038-01-19 03:14:07 UTC, 32-bit signed time_t will overflow
• Check whether your OS, language runtime, and DB use 64-bit time representations

Leap Seconds

• Most systems assume 1 day = 86400 seconds and ignore leap seconds
• NTP or Google’s “smear” method can affect how the boundary is handled

Time Zones

• Always store in UTC, convert to local zone only on input/output
• Watch out for unit mismatches (seconds vs milliseconds) in APIs and DBs

Best Practices

Consistency across logging, APIs, databases, and UI helps prevent unit/time-zone related bugs.

Recommendations

• Store in UTC (Unix seconds or ISO8601 UTC string)
• Document interface specs: unit (sec/ms) and time zone
• Include boundary cases in testing (leap years, month-end, midnight, unit mismatches)
• For observability, log both UTC and local time when possible

FAQ

Q. Is Unix Time in JST?

• A. No. It is always in UTC. JST is applied only for display conversion.

Q. What is the difference between 10-digit and 13-digit values?

• A. 10 digits usually means seconds, 13 digits usually means milliseconds.

Q. Does the Year 2038 problem affect me?

• A. It affects 32-bit systems using signed time_t. On 64-bit systems it is not an issue.

Where Unix Time is Used

Examples

• Timestamps in server logs and monitoring
• API tokens and expiration (exp, iat, etc.)
• Database event times, sorting, and range queries
• Frontend relative time display (e.g., "5 minutes ago")