These SQL examples use Unix seconds for the portable baseline and show milliseconds only where the runtime exposes them naturally. The question to answer before copying a snippet is simple: what unit does the next API expect?

Get the current Unix time

-- PostgreSQL
SELECT EXTRACT(EPOCH FROM NOW())::bigint;

-- MySQL
SELECT UNIX_TIMESTAMP();

Convert a timestamp to UTC

-- PostgreSQL
SELECT to_timestamp(1700000000);

-- MySQL
SELECT FROM_UNIXTIME(1700000000);

Production note

Database functions vary by engine and session timezone. Use timezone-aware column types where available, and define range boundaries in one declared unit.

Keep the unit in the field name when a value crosses a boundary: createdAtSeconds and createdAtMs are longer than createdAt, but much less mysterious during an incident.

Frequent questions:

Q: Should epoch milliseconds be stored in INT?
A: No. Modern millisecond timestamps are 13 digits and do not fit safely in a 32-bit INT. Use BIGINT or a native timestamp type.
Q: Are database timestamps always UTC?
A: No. Behavior depends on the database type and session timezone. Be explicit about UTC when importing, exporting, and comparing values across systems.