Convertisseur de Timestamps

What is a Unix Timestamp?

A Unix timestamp (also called POSIX time or Epoch time) is a system for representing a specific point in time as a single integer — the number of seconds that have elapsed since the Unix Epoch, defined as January 1, 1970 at 00:00:00 UTC. This deceptively simple convention underpins virtually every modern computing system: databases store creation dates as timestamps, APIs transmit event times as integers, log files record millisecond-precision moments, and distributed systems synchronize clocks using the same reference point. Converting between human-readable dates and Unix timestamps is one of the most common operations in software development, debugging, and systems administration.

The Unix Epoch and POSIX Time

The Unix Epoch — January 1, 1970, 00:00:00 UTC — was chosen as the zero-point for timekeeping across Unix-like operating systems. Every second since that moment increments the counter by one. The POSIX standard (IEEE Std 1003.1) formally defines this as "seconds since the Epoch," explicitly excluding leap seconds from the count. This means a POSIX timestamp does not precisely track International Atomic Time (TAI), but it guarantees that every day is exactly 86,400 seconds long, simplifying arithmetic enormously.

The original Unix time was stored as a signed 32-bit integer, which can represent dates from December 13, 1901 to January 19, 2038. The infamous Year 2038 Problem (Y2K38) occurs when this counter overflows on January 19, 2038 at 03:14:07 UTC. Modern systems have largely migrated to 64-bit integers, extending the representable range to approximately 292 billion years in either direction — effectively unlimited for any practical purpose.

Negative timestamps represent dates before the Epoch. For example, -86400 represents December 31, 1969 at 00:00:00 UTC. This allows Unix timestamps to represent historical dates, though precision and calendar system differences make very old dates unreliable.

Timestamp Formats and Precision

Unix timestamps come in several precision levels, and confusing them is a frequent source of bugs:

• Seconds (s): The classic Unix timestamp. 10 digits for current dates (e.g., 1700000000). Used by most Unix utilities, PHP's time(), Python's time.time(), and SQL's UNIX_TIMESTAMP().
• Milliseconds (ms): 13 digits (e.g., 1700000000000). Used by JavaScript's Date.now(), Java's System.currentTimeMillis(), and most JSON APIs. One thousand times more precise than seconds.
• Microseconds (μs): 16 digits. Used by PostgreSQL's CURRENT_TIMESTAMP, Python's datetime module, and high-resolution performance timers.
• Nanoseconds (ns): 19 digits. Used by Go's time.Now().UnixNano(), Rust's SystemTime, and hardware-level timing operations.

A common mistake is passing a millisecond timestamp to a function that expects seconds, resulting in dates thousands of years in the future. This tool automatically detects whether an input is in seconds (10 digits) or milliseconds (13 digits) and converts accordingly. When in doubt, check the digit count: 10 digits means seconds, 13 means milliseconds.

ISO 8601 and Human-Readable Formats

While timestamps are efficient for storage and computation, humans need readable date strings. ISO 8601 is the international standard for date and time representation, and its most common format looks like: 2024-01-15T09:30:00.000Z. The trailing Z denotes UTC (Zulu time). Offsets like +05:30 or -08:00 indicate local time zones relative to UTC.

ISO 8601 is the preferred interchange format for APIs, databases, and log files because it is unambiguous, sortable as a string, and universally parseable. Unlike regional formats (MM/DD/YYYY vs DD/MM/YYYY), ISO 8601 eliminates confusion about month-day ordering. The format also supports durations (P1Y2M3D), intervals, and recurring time periods.

This tool converts between Unix timestamps and ISO 8601 strings bidirectionally. Enter a numeric timestamp to see the corresponding ISO 8601 date, or enter a date string to obtain the Unix timestamp in both seconds and milliseconds.

Time Zones and UTC in Practice

Unix timestamps are always in UTC — they represent an absolute moment in time independent of any time zone. However, displaying that moment to a user requires converting to their local time zone. This conversion depends on the IANA Time Zone Database (also called the Olson database), which tracks historical and future UTC offsets for every region, including daylight saving transitions.

Common pitfalls when working with timestamps and time zones include:

• Storing local time instead of UTC: Always store timestamps in UTC and convert to local time only at display time. This prevents ambiguity during DST transitions.
• Assuming fixed UTC offsets: Time zones change rules frequently. India is always UTC+5:30, but the US shifts between EST (UTC-5) and EDT (UTC-4) twice per year.
• Ignoring DST "fold" hours: When clocks fall back, the same local time occurs twice. Without UTC storage, you cannot distinguish between the two occurrences.
• Using abbreviations (PST, CST): These are ambiguous — CST could mean Central Standard Time (UTC-6), China Standard Time (UTC+8), or Cuba Standard Time (UTC-5). Use IANA identifiers like America/Chicago instead.

JavaScript's Intl.DateTimeFormat API handles time zone conversion correctly using the IANA database. For server-side code, libraries like date-fns-tz (JavaScript), pytz / zoneinfo (Python), or java.time.ZonedDateTime (Java) provide robust time zone support.

Code Examples

Converting between timestamps and dates in JavaScript

// Current Unix timestamp in seconds and milliseconds
const nowMs = Date.now();           // 1700000000000 (milliseconds)
const nowSec = Math.floor(nowMs / 1000); // 1700000000 (seconds)

// Timestamp → Human-readable date
const date = new Date(1700000000 * 1000); // multiply seconds by 1000
console.log(date.toISOString());
// → "2023-11-14T22:13:20.000Z"

// Human-readable date → Timestamp
const ts = new Date('2024-06-15T12:00:00Z').getTime();
console.log(ts);       // 1718452800000 (milliseconds)
console.log(ts / 1000); // 1718452800 (seconds)

// Display in a specific time zone
const formatted = new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York',
  dateStyle: 'full',
  timeStyle: 'long'
}).format(new Date(1700000000000));
// → "Tuesday, November 14, 2023 at 5:13:20 PM EST"

Timestamp operations in Python and SQL

import time
from datetime import datetime, timezone

# Current timestamp (seconds with decimal precision)
now = time.time()  # 1700000000.123456

# Timestamp → datetime (UTC)
dt = datetime.fromtimestamp(1700000000, tz=timezone.utc)
print(dt.isoformat())  # "2023-11-14T22:13:20+00:00"

# datetime → timestamp
ts = datetime(2024, 6, 15, 12, 0, 0, tzinfo=timezone.utc).timestamp()
print(int(ts))  # 1718452800

# --- SQL examples ---
# MySQL: SELECT UNIX_TIMESTAMP('2024-01-15 09:30:00');
# PostgreSQL: SELECT EXTRACT(EPOCH FROM TIMESTAMP '2024-01-15 09:30:00');
# SQLite: SELECT strftime('%s', '2024-01-15 09:30:00');

Standards & Specifications

• POSIX.1-2017 (IEEE Std 1003.1) — Formal definition of "Seconds Since the Epoch" — the authoritative source for Unix time semantics
• ISO 8601:2019 — International standard for date and time interchange formats, including the YYYY-MM-DDTHH:mm:ssZ notation
• IANA Time Zone Database — The definitive source for global time zone rules, DST transitions, and historical offset data