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.