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.
📅 Published July 2026·⏳ 9 min read·✍️ ToolsNovaHub Editorial Team
Nearly every application eventually needs to convert between Unix timestamps and human-readable dates — but each language has its own quirks around units (seconds vs milliseconds), timezone handling, and formatting functions. This guide gives you working, tested code for the three most common languages, plus the specific mistakes that cause the most bugs in practice.
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
Does JavaScript use seconds or milliseconds for timestamps? +
Milliseconds — Date.now() and new Date() both operate in milliseconds, unlike the traditional Unix seconds convention used by most other languages.
Why does Python's datetime.fromtimestamp() sometimes give unexpected results? +
Without explicitly passing tz=timezone.utc, it uses your system's local timezone, which can silently produce different results depending on where the code runs.
How do I convert JavaScript milliseconds to a format Python expects? +
Divide by 1000 and typically floor the result: Math.floor(jsTimestamp / 1000) in JavaScript, or simply divide by 1000 before passing the value to Python's fromtimestamp().
What is the safest general pattern for handling timestamps across a full-stack app? +
Store and compute in UTC internally throughout your entire stack, and convert to a specific display timezone only at the final rendering step, never in intermediate logic.
Does PHP's time() return seconds or milliseconds? +
Seconds — consistent with the traditional Unix time convention, unlike JavaScript's millisecond-based Date.now().
Why shouldn't I store dates as formatted strings in a database? +
It makes proper sorting, comparison, filtering, and timezone conversion needlessly error-prone — store as a native timestamp or date column type and format only when displaying to a user.
How do I get the current Unix timestamp in seconds in JavaScript? +
Math.floor(Date.now() / 1000) — dividing the millisecond value by 1000 and flooring it to a whole-second integer.
What's the risk of parsing a date-only string like '2026-07-02'? +
Depending on the parser and environment, it can resolve to midnight in different timezones, occasionally shifting the interpreted date by a day compared to what was intended.
Does Python's time.time() return an integer or a float? +
A float, with sub-second precision — be careful when comparing it against integer-second timestamps from other sources, as naive comparisons can produce subtle off-by-fractions issues.
How do I format a Unix timestamp as a readable date in PHP? +
Using date('Y-m-d H:i:s', $timestamp) for a simple case, or the more timezone-aware DateTime class for anything requiring explicit timezone handling.
Can I safely pass a Unix timestamp between a JavaScript frontend and Python backend? +
Yes, as long as both sides agree explicitly on the unit (seconds or milliseconds) — mismatched units are the most common bug in this exact scenario.
What's the best way to debug a timestamp that looks wrong? +
Paste it into our Unix Timestamp Converter and check both the seconds and milliseconds interpretation — this instantly reveals whether a 1000x unit mismatch is the culprit.
Does SQL use seconds or milliseconds for Unix timestamp functions? +
Traditionally seconds — functions like MySQL's FROM_UNIXTIME() expect a seconds-based Unix timestamp, not milliseconds.
Why is UTC generally recommended over local time for internal storage? +
UTC has no daylight saving transitions or ambiguous repeated hours, making arithmetic and comparisons reliably correct regardless of where your servers or users are physically located.
Is there a risk in using timestamps for very precise sub-second timing? +
Standard Unix timestamps are second-precision; for sub-second timing needs, use a language's dedicated high-resolution timer (like JavaScript's performance.now()) rather than relying on timestamp precision alone.
✓ Reviewed by: ToolsNovaHub Editorial Team📅 Last updated: July 2026📜 Sourced from: official RFC / vendor documentation
ToolsNovaHub tools are built and independently maintained with a focus on accurate, no-signup network and security utilities. Spotted an error? Let us know.
🎓
Expert Tip
Time conversions are sensitive to Daylight Saving Time — when using Working with Unix Timestamps in JavaScript, Python & PHP for a future date, verify against the target region's current DST rules for that date, not today's.
⭐
ToolsNovaHub Pro Tip
Save your frequently-used timezone pairs or reference dates so Working with Unix Timestamps in JavaScript, Python & PHP becomes a one-click check during recurring scheduling.
⚠️
Common Beginner Mistake
Forgetting that a UTC offset shown by Working with Unix Timestamps in JavaScript, Python & PHP for a city today may not hold for a past or future date because of DST — always compute for the specific date.