UNIX Timestamp Converter: Seconds vs Milliseconds, Time Zones & Common Pitfalls

What is UNIX time?

UNIX time counts seconds since the Unix epoch: 1970-01-01T00:00:00Z (UTC). It’s timezone-agnostic for storage and comparison. Applications can format it into local time for display.

Key benefits: fast comparisons, easy math, and universal semantics across languages and databases.

Seconds vs milliseconds

• Seconds: typical for POSIX systems and many APIs. Example: 1735689600.
• Milliseconds: common in JavaScript and some cloud logs. Example: 1735689600000.

# Convert ms → s
1735689600000 / 1000 = 1735689600

# Convert s → ms
1735689600 * 1000 = 1735689600000

Tip: Count digits. 10 ≈ seconds, 13 ≈ milliseconds.

Time zones & UTC offsets

Store and transmit in UTC. Convert to local time only for UI. Avoid hardcoding offsets like +05:30—use a proper time zone library (IANA TZ database) to handle daylight saving and historical changes.

# ISO-8601 examples (always include offset or 'Z' for UTC)
2025-04-10T14:00:00Z
2025-04-10T14:00:00+00:00
2025-04-10T09:00:00-05:00

Daylight Saving pitfalls

• Ambiguous/Skipped times: Local clock changes can repeat or skip an hour. Convert to UTC before math.
• Scheduling: Store in UTC + a time-zone identifier (e.g., America/New_York) to re-render correctly later.
• Reports: Prefer zoned date-times for display, but keep raw data in UTC.

Code examples (JavaScript, Python, PHP)

JavaScript

// Seconds → Date (UTC display)
const secs = 1735689600;
const dUTC = new Date(secs * 1000);
console.log(dUTC.toISOString()); // 2025-01-01T00:00:00.000Z

// Milliseconds now
const nowMs = Date.now();

// Format in local time
const dLocal = new Date(secs * 1000);
console.log(dLocal.toLocaleString());

Python

import datetime, zoneinfo

secs = 1735689600
dt_utc = datetime.datetime.fromtimestamp(secs, datetime.timezone.utc)
print(dt_utc.isoformat())  # 2025-01-01T00:00:00+00:00

# Convert to New York time
ny = zoneinfo.ZoneInfo("America/New_York")
print(dt_utc.astimezone(ny).isoformat())

PHP

<?php
$secs = 1735689600;
$dt = new DateTime("@$secs");         // "@" treats number as epoch seconds (UTC)
$dt->setTimezone(new DateTimeZone("UTC"));
echo $dt->format(DateTime::ATOM);     // 2025-01-01T00:00:00+00:00

// Convert to Asia/Kolkata
$dt->setTimezone(new DateTimeZone("Asia/Kolkata"));
echo "\n".$dt->format("Y-m-d H:i:sP");
?>

Sanity-check checklist

• Does the number have 10 digits (seconds) or 13 digits (ms)?
• Convert to UTC and confirm the ISO-8601 looks plausible (date range, hour, etc.).
• Round-trip: parse → format → parse again; verify it’s the same timestamp.
• Spot-check around DST changes (spring forward / fall back).

Troubleshooting

Time is off by ~3 hours (or similar): You likely converted using a local offset. Convert in UTC first, then format for display.

13-digit timestamp looks like year 51390: You treated milliseconds as seconds. Divide by 1000.

API returns a string like “2025-04-10T14:00:00Z”: That’s already UTC ISO-8601—parse it as a DateTime and avoid manual math.