Unix Timestamp Cheat Sheet

Quick reference

"Native unit" is what that language's most common built-in call returns by default — most languages default to seconds; JavaScript and Java default to milliseconds. This is the single most common source of 1000x-off bugs when passing a timestamp between two languages.

Seconds vs. milliseconds — the fast way to tell

A Unix timestamp in seconds is currently a 10-digit number (it stays 10 digits until the year 2286). The same instant in milliseconds is a 13-digit number. If you're eyeballing an unfamiliar timestamp and it's 13 digits, it's milliseconds — divide by 1000 before treating it as seconds, or you'll land in the year 1970-something instead of today.

JavaScript

// Current time
Date.now()                        // milliseconds, e.g. 1757757600000
Math.floor(Date.now() / 1000)     // seconds

// Timestamp -> Date (expects milliseconds)
new Date(1757757600000)
new Date(1757757600 * 1000)       // convert from seconds first

// Date -> timestamp
someDate.getTime()                          // milliseconds
Math.floor(someDate.getTime() / 1000)       // seconds

new Date(ts).toString() prints in the browser's local time zone. Use .toUTCString() or .toISOString() when you need UTC — mixing these up is the most common source of off-by-several-hours bugs in JS date code.

Python

import time
from datetime import datetime, timezone

# Current time
time.time()                 # seconds, as a float, e.g. 1757757600.123
int(time.time())            # seconds, as an int

# Timestamp -> datetime
datetime.fromtimestamp(1757757600, tz=timezone.utc)   # UTC-aware (recommended)
datetime.fromtimestamp(1757757600)                    # local time zone

# datetime -> timestamp
some_datetime.timestamp()   # seconds (float)

datetime.utcfromtimestamp() and datetime.utcnow() are deprecated as of Python 3.12 in favor of the timezone-aware form above, since they silently return a "naive" datetime with no timezone attached.

Java

// Current time
System.currentTimeMillis()              // milliseconds
Instant.now().getEpochSecond()          // seconds
Instant.now().toEpochMilli()            // milliseconds

// Timestamp -> Instant
Instant.ofEpochSecond(1757757600)
Instant.ofEpochMilli(1757757600000L)

Java has two competing conventions in active use: the legacy System.currentTimeMillis() (milliseconds) and the modern java.time.Instant API, which offers both units explicitly rather than defaulting to one — prefer Instant in new code specifically because it forces you to be explicit.

PHP

// Current time
time()                              // seconds
round(microtime(true) * 1000)       // milliseconds

// Timestamp -> date string
date('Y-m-d H:i:s', 1757757600)     // local time zone (per date_default_timezone_set)
gmdate('Y-m-d H:i:s', 1757757600)   // UTC

// date string -> timestamp
strtotime('2026-09-13 12:00:00')

Go

// Current time
time.Now().Unix()          // seconds
time.Now().UnixMilli()     // milliseconds (Go 1.17+)

// Timestamp -> time.Time
time.Unix(1757757600, 0)             // seconds, nanoseconds
time.UnixMilli(1757757600000)        // milliseconds (Go 1.17+)

Ruby

# Current time
Time.now.to_i                     # seconds
(Time.now.to_f * 1000).to_i       # milliseconds

# Timestamp -> Time
Time.at(1757757600)               # local time zone
Time.at(1757757600).utc           # UTC

SQL — MySQL & PostgreSQL

-- MySQL
SELECT UNIX_TIMESTAMP();                     -- current time, seconds
SELECT FROM_UNIXTIME(1757757600);            -- timestamp -> datetime
SELECT UNIX_TIMESTAMP(some_datetime_col);    -- datetime -> timestamp

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW());            -- current time, seconds (numeric)
SELECT TO_TIMESTAMP(1757757600);             -- timestamp -> timestamptz (UTC)

Unix shell

# Current time
date +%s

# Timestamp -> readable date
date -d @1757757600          # GNU/Linux
date -r 1757757600           # macOS / BSD (different flag, same result)

C# / .NET

// Current time
DateTimeOffset.UtcNow.ToUnixTimeSeconds()
DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()

// Timestamp -> DateTimeOffset
DateTimeOffset.FromUnixTimeSeconds(1757757600)
DateTimeOffset.FromUnixTimeMilliseconds(1757757600000)

Excel & Google Sheets

' Unix timestamp (seconds, in cell A1) -> date
=(A1/86400)+DATE(1970,1,1)
' Format the resulting cell as Date or Date/Time to see it correctly

' Date (in cell A1) -> Unix timestamp
=(A1-DATE(1970,1,1))*86400

The formula is identical in Excel and Google Sheets, since both use the same underlying date-serial-number system (days since a fixed reference date). Divide by 86400 (seconds per day) to convert seconds into days, then add that to the epoch date; format the result cell as a date or date/time to display it properly instead of a raw number. If your timestamp is in milliseconds, divide by 86400000 instead.

UTC and time zones

A Unix timestamp itself has no time zone — it's a count of seconds (or milliseconds) since January 1, 1970, 00:00:00 UTC, and it represents exactly one instant regardless of where in the world you are. Time zones only enter the picture when you convert that instant into a human-readable calendar date and clock time — "2026-09-13 14:00" means a different instant depending on whether it's in UTC, US Eastern, or IST. The bugs almost always come from a conversion step silently defaulting to the server's or browser's local time zone when UTC was intended, or vice versa — the JavaScript and PHP examples above call that out at the exact line where it happens.

Convert one right now

Need to convert an actual value instead of copying a snippet? QuickTiny's Unix Timestamp Converter converts between a timestamp and a local/UTC date instantly, free, with nothing sent to a server.

Frequently asked questions

Why do some languages use seconds and others milliseconds?

There's no technical reason they had to differ — it's historical. The original Unix epoch definition from the 1970s used seconds, and most systems-level and Unix-adjacent languages (C, Python, Go, Ruby, PHP, SQL) kept that convention. JavaScript's Date object was specified in 1995 to use milliseconds for finer precision in the browser, and Java's System.currentTimeMillis() followed a similar logic. Neither is "wrong" — they just don't agree, which is why conversions between them are a common bug source.

How do I know which unit an unfamiliar timestamp is in?

Count the digits. A current-era timestamp in seconds is 10 digits; in milliseconds it's 13 digits. A value like 1757757600 is seconds; 1757757600000 is milliseconds.

Does a Unix timestamp change if I'm in a different time zone?

No. The timestamp itself is a single, time-zone-independent instant. Only the human-readable date/time you convert it to changes depending on which time zone you display it in.

What's the largest date a Unix timestamp can represent?

A signed 32-bit timestamp (still used in some older systems) overflows in January 2038 — the "Year 2038 problem." Modern 64-bit timestamps, which is what all the languages above use by default today, are effectively unbounded for any practical date.

Is this page kept up to date?

The APIs shown here are long-stable language features, not likely to change, but syntax and defaults can shift over major language versions (as happened with Python 3.12 deprecating naive-UTC helpers, noted above). If you're relying on this for something time-sensitive, cross-check against your language's current official documentation.