How to Convert a Timestamp to a Date in JavaScript, Python, and SQL

Every backend log, JWT token, analytics event, and database row eventually hands you a number like 1720000000 and expects you to know what moment in time it represents. This is a Unix timestamp — the count of seconds since 1 January 1970 UTC — and converting it to a readable date is one of the most repeated tasks in day-to-day development. This cookbook collects the exact snippets you need for JavaScript, Python, MySQL, and PostgreSQL, in both directions, along with the one gotcha that causes more bugs than everything else combined: seconds versus milliseconds.

JavaScript: new Date(), Date.now(), and Intl.DateTimeFormat

JavaScript is the language where the seconds-vs-milliseconds trap bites first, because the Date constructor expects milliseconds, while almost every API and database hands you seconds. Multiply by 1000 when converting a Unix timestamp:

// Unix timestamp (seconds) -> Date object
const ts = 1720000000;               // seconds since epoch
const date = new Date(ts * 1000);    // Date wants milliseconds!

console.log(date.toISOString());     // "2024-07-03T09:46:40.000Z"
console.log(date.toLocaleString());  // local time, e.g. "3/7/2024, 3:16:40 pm" in IST

// Current time, both units
Date.now();                          // 1752537600000  (milliseconds)
Math.floor(Date.now() / 1000);       // 1752537600     (seconds, Unix style)

// Date object -> Unix timestamp
Math.floor(date.getTime() / 1000);   // back to 1720000000

For display in a specific format or timezone, skip manual string building and use Intl.DateTimeFormat, which is built into every modern browser and Node.js:

const fmt = new Intl.DateTimeFormat('en-IN', {
  dateStyle: 'medium',
  timeStyle: 'short',
  timeZone: 'Asia/Kolkata',
});
fmt.format(new Date(1720000000 * 1000));
// "3 Jul 2024, 3:16 pm"

Python: datetime.fromtimestamp and .timestamp()

Python's datetime module works in seconds (as a float), so no multiplication is needed — but there is a different trap. Calling fromtimestamp() without a timezone returns local time, which means the same code produces different results on your laptop (IST) and your server (usually UTC). Always pass a timezone explicitly:

from datetime import datetime, timezone

ts = 1720000000

# Timestamp -> aware datetime (recommended: always pass tz)
dt_utc = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt_utc)                # 2024-07-03 09:46:40+00:00
print(dt_utc.isoformat())    # "2024-07-03T09:46:40+00:00"

# Display in IST using zoneinfo (Python 3.9+)
from zoneinfo import ZoneInfo
dt_ist = datetime.fromtimestamp(ts, tz=ZoneInfo("Asia/Kolkata"))
print(dt_ist)                # 2024-07-03 15:16:40+05:30

# Datetime -> timestamp
dt_utc.timestamp()           # 1720000000.0
int(datetime.now(tz=timezone.utc).timestamp())  # current Unix time

• Avoid datetime.utcnow() — it returns a naive datetime (no tzinfo) and is deprecated since Python 3.12. Use datetime.now(timezone.utc) instead.
• Calling .timestamp() on a naive datetime assumes local time, which silently shifts the value by your machine's UTC offset.

MySQL: FROM_UNIXTIME and UNIX_TIMESTAMP

MySQL has a matched pair of functions. FROM_UNIXTIME() converts a number into a DATETIME, and UNIX_TIMESTAMP() goes back the other way. Both respect the session time_zone variable, so check what your connection is set to before trusting the output:

-- Timestamp -> datetime
SELECT FROM_UNIXTIME(1720000000);
-- 2024-07-03 09:46:40   (when time_zone = '+00:00')

-- With a custom display format
SELECT FROM_UNIXTIME(1720000000, '%d %b %Y %h:%i %p');
-- 03 Jul 2024 09:46 AM

-- Datetime -> timestamp
SELECT UNIX_TIMESTAMP('2024-07-03 09:46:40');   -- 1720000000
SELECT UNIX_TIMESTAMP();                        -- current Unix time

-- Filter rows stored as epoch seconds
SELECT * FROM events
WHERE created_at >= UNIX_TIMESTAMP('2024-07-01')
  AND created_at <  UNIX_TIMESTAMP('2024-08-01');

PostgreSQL: to_timestamp and extract(epoch)

PostgreSQL uses to_timestamp() to turn epoch seconds into a timestamptz (timestamp with time zone), and extract(epoch from ...) to convert back:

-- Timestamp -> timestamptz
SELECT to_timestamp(1720000000);
-- 2024-07-03 09:46:40+00

-- Display in IST
SELECT to_timestamp(1720000000) AT TIME ZONE 'Asia/Kolkata';
-- 2024-07-03 15:16:40

-- Timestamptz -> epoch seconds
SELECT extract(epoch FROM timestamptz '2024-07-03 09:46:40+00');
-- 1720000000

-- Current Unix time
SELECT extract(epoch FROM now())::bigint;

Note that extract(epoch ...) returns a numeric with fractional seconds; cast to bigint when you need a clean integer. Also, to_timestamp() happily accepts a millisecond value and produces a date tens of thousands of years in the future — divide by 1000 first if your source is in milliseconds.

The Gotchas That Cause Real Bugs

• Seconds vs milliseconds — Unix timestamps are 10 digits today; JavaScript milliseconds are 13. A date showing January 1970 means you passed seconds where milliseconds were expected; a date in the year 56789 means the opposite.
• Implicit local time — Python's fromtimestamp() without tz, MySQL's session time_zone, and JavaScript's toLocaleString() all depend on environment settings. Be explicit everywhere.
• Float precision — Python and PostgreSQL return fractional seconds. Truncate deliberately with int() or ::bigint rather than letting rounding decide.
• String timestamps — JSON delivers numbers as strings more often than you expect. new Date("1720000000000") is Invalid Date; parse with Number() first.
• Negative timestamps — dates before 1970 are valid negative values. All four environments handle them, but naive validation like ts > 0 rejects them.

Frequently Asked Questions