PHP Unix Timestamp: time(), microtime & DateTime Zones

time() and microtime(true), in seconds

time() returns whole seconds. For milliseconds, use microtime(true), which returns a float in seconds with microsecond precision — multiply by 1000 and truncate.

<?php
$sec = time();                          // 1767225600 (whole seconds)
$ms  = (int) round(microtime(true) * 1000);   // milliseconds
$us  = (int) round(microtime(true) * 1000000); // microseconds

// microtime(false) returns "0.123456 1767225600" — parse it if you need both parts
list($usec, $sec2) = explode(' ', microtime());

date() vs DateTimeImmutable::setTimestamp()

Two idioms: the procedural date() and the object-oriented DateTimeImmutable::setTimestamp(). Both format in the default timezone — configured with date_default_timezone_set() or php.ini. Never rely on that default being UTC.

<?php
$ts = 1767225600;

echo date('Y-m-d H:i:s', $ts);          // uses the DEFAULT timezone

$dt = (new DateTimeImmutable())->setTimestamp($ts);
echo $dt->format('Y-m-d H:i:s P');      // e.g. 2026-01-01 00:00:00 +00:00

$ist = $dt->setTimezone(new DateTimeZone('Asia/Kolkata'));
echo $ist->format('Y-m-d H:i:s P');     // 2026-01-01 05:30:00 +05:30

strtotime() and the default-timezone trap

Parsing is where PHP's defaults bite hardest: strtotime() and new DateTime($string) interpret zone-less strings in the default timezone. For UTC input, use a Z suffix or build the DateTime from parts with an explicit zone.

<?php
$ts = strtotime('2026-01-01 00:00:00');           // DEFAULT zone — machine-dependent
$ts = strtotime('2026-01-01 00:00:00 UTC');       // explicit, deterministic

$dt = new DateTimeImmutable('2026-01-01 00:00:00', new DateTimeZone('UTC'));
$dt->getTimestamp();                              // 1767225600

// DateTimeImmutable::createFromFormat locks the format AND the zone
$dt2 = DateTimeImmutable::createFromFormat('!Y-m-d H:i:s', '2026-01-01 00:00:00', new DateTimeZone('UTC'));

Timezone-aware vs naive (and mutable vs immutable)

PHP's DateTime is always zone-aware — it always carries a DateTimeZone. The naivety problem is inverted: if you don't set a zone, PHP imposes the global default on you. The other trap is mutation: DateTime methods (setTimestamp, setTimezone) mutate the object and return $this, which makes copy bugs easy. DateTimeImmutable returns new objects and is the safe default.

<?php
// Mutable: both variables share one object
$a = new DateTime('2026-01-01', new DateTimeZone('UTC'));
$b = $a->setTimezone(new DateTimeZone('Asia/Kolkata'));
echo $a->format('H:i');   // 05:30 — $a changed too!

// Immutable: $a keeps its value
$a = new DateTimeImmutable('2026-01-01', new DateTimeZone('UTC'));
$b = $a->setTimezone(new DateTimeZone('Asia/Kolkata'));
echo $a->format('H:i');   // 00:00 ✓

Native precision in PHP: seconds (ms via microtime)

time() is whole seconds. Millisecond and microsecond values come from microtime(true) or from DateTime only after PHP 7.1's microsecond support in the constructor/format strings. Everything downstream is integer epoch — exactly what the converter expects when you paste a 10-, 13-, or 16-digit value.

PHP pitfalls: server timezone and mutable DateTime

• Default timezone — set date_default_timezone_set('UTC') early, or every date() call shifts with the server.
• strtotime('2026-01-01') — local midnight, not UTC midnight.
• Mutable DateTime — setTimezone() changes the original; use DateTimeImmutable.
• Timestamp range — 32-bit PHP wraps in 2038; run 64-bit builds (PHP 8 is 64-bit-only).

Compare the PHP output in the live converter

Verify any value against these snippets in the main epoch converter, or copy the current timestamp from the PHP snippet tab on the homepage.