Working with Unix Timestamps in JavaScript, Python & PHP
Every language handles Unix timestamps slightly differently. Here's exactly how to convert, format, and compare them correctly in the three most common ones.
JavaScript
JavaScript's Date object uses milliseconds, not seconds — the single most common source of off-by-1000x bugs when working across languages.
// Current timestamp (seconds)
const nowSeconds = Math.floor(Date.now() / 1000);
// Timestamp (seconds) to Date
const d = new Date(1751328000 * 1000);
// Date to timestamp (seconds)
const ts = Math.floor(new Date('2026-07-02').getTime() / 1000);
// Format as ISO string
d.toISOString(); // "2026-07-02T00:00:00.000Z"
Python
Python's standard library uses seconds as floats, matching the traditional Unix convention.
import time
from datetime import datetime, timezone
# Current timestamp
now = time.time() # e.g. 1751328000.123
# Timestamp to datetime (local)
dt = datetime.fromtimestamp(1751328000)
# Timestamp to datetime (explicit UTC — recommended)
dt_utc = datetime.fromtimestamp(1751328000, tz=timezone.utc)
# Datetime to timestamp
ts = dt_utc.timestamp()
Always prefer the explicit tz=timezone.utc variant — datetime.fromtimestamp() without it silently uses your system's local timezone, a frequent source of subtle bugs when code runs on servers in different timezones than expected.
PHP
PHP also uses seconds, with a rich built-in date formatting function.
// Current timestamp
$now = time();
// Timestamp to formatted date
echo date('Y-m-d H:i:s', 1751328000);
// Date string to timestamp
$ts = strtotime('2026-07-02');
// DateTime object approach (timezone-aware)
$dt = new DateTime('@1751328000');
$dt->setTimezone(new DateTimeZone('UTC'));
echo $dt->format('Y-m-d H:i:s');
Cross-Language Mistakes to Avoid
- Passing JavaScript milliseconds to a seconds-expecting API: Extremely common when a JS frontend sends
Date.now()directly to a Python or PHP backend expecting seconds — always divide by 1000 first, or be explicit about units in your API contract. - Ignoring timezone in date-only strings: Parsing
"2026-07-02"without a time component can resolve to midnight in different timezones depending on the parser, sometimes shifting the resulting date by a day. - Storing formatted date strings instead of timestamps or proper date types: Makes comparison, sorting, and timezone conversion needlessly error-prone — store as a proper timestamp or database date type, and format only at display time.
- Float precision issues: Python's
time.time()returns a float with sub-second precision — truncating carelessly when comparing against integer-second values elsewhere can cause off-by-one comparison bugs.
Getting Timezone Handling Right
The safest general pattern across all languages: store and compute in UTC internally, and convert to a specific timezone only at the final display step. Mixing local-timezone logic into internal calculations is one of the most persistent sources of date bugs across every language covered here. Pair this with our Timezone Converter when you need to reason about a specific target timezone for display purposes.
For quick manual conversion without writing code, our Unix Timestamp Converter also shows the exact code snippet for a given timestamp across JavaScript, Python, PHP, and SQL.
FAQs
ToolsNovaHub guides are researched against primary sources (RFCs, vendor docs) and kept up to date as standards change. Spotted an error? Let us know.
📋 Related Tools & Guides Comparison
| Resource | Type | Link |
|---|---|---|
| Timezone Converter | Time | Open Tool → |
| Age Calculator | Time | Open Tool → |
| Unix Timestamp Converter | Time | Open Tool → |
| Age Calculator Guide: Leap Years, Legal Age & Calendar History | Guide | Read Guide → |
| Timezone Converter Guide: DST, UTC & Global Meeting Scheduling | Guide | Read Guide → |