MySQL用FROM_UNIXTIME()转秒级时间戳，PostgreSQL需TO_TIMESTAMP()配合类型转换，SQLite依赖datetime()加unixepoch修饰符；三者单位、类型、函数均不兼容，须在应用层统一处理。

MySQL里用 FROM_UNIXTIME() 转秒级时间戳

MySQL原生支持秒级Unix时间戳（10位整数）转日期，直接用 FROM_UNIXTIME() 就行。它默认返回 YYYY-MM-DD HH:MM:SS 格式，可读性强，也支持自定义格式。

常见错误是传入毫秒级时间戳（13位），结果变成公元3万年——因为MySQL按秒处理，13位会被当“秒”解析。

• 正确用法：SELECT FROM_UNIXTIME(1717027200); → 2024-05-31 00:00:00
• 转指定格式：SELECT FROM_UNIXTIME(1717027200, '%Y年%m月%d日 %H:%i');
• 若字段是毫秒级，先除以1000：FROM_UNIXTIME(UNIX_TIMESTAMP_COLUMN / 1000)

PostgreSQL中用 TO_TIMESTAMP() 处理秒和毫秒

PostgreSQL的 TO_TIMESTAMP() 默认接收的是秒级浮点数，但必须注意：它把输入当作“秒 since epoch”，不接受整数类型直接传入（会报错“function to_timestamp(integer) does not exist”）。

常见坑是没显式转类型，或混淆毫秒/秒单位。

• 秒级整数：写成 TO_TIMESTAMP(1717027200::double precision)
• 毫秒级整数：先除以1000，再转浮点：TO_TIMESTAMP(1717027200000::double precision / 1000)
• 配合 AT TIME ZONE 调时区：TO_TIMESTAMP(1717027200)::timestamptz AT TIME ZONE 'Asia/Shanghai'

SQLite里没有内置函数，得靠 datetime() + unixepoch

SQLite不认 FROM_UNIXTIME 或 TO_TIMESTAMP，但它在 datetime() 函数里悄悄支持了 unixepoch 修饰符——这是唯一可靠方式。

关键点：unixepoch 只接受秒级整数；传毫秒会溢出为错误日期（比如显示1970年）。

• 标准用法：SELECT datetime(1717027200, 'unixepoch');
• 加本地时区偏移：SELECT datetime(1717027200, 'unixepoch', 'localtime');
• 毫秒需先整除：datetime(1717027200000 / 1000, 'unixepoch')（注意用 / 不是 //，SQLite整除会截断）

跨数据库兼容写法几乎不存在，别硬套

三个主流数据库的函数名、参数类型、单位约定全都不一样：MySQL吃整数秒，PostgreSQL要浮点秒，SQLite靠修饰符。试图用一层封装函数“统一接口”反而容易在边界 case（比如0、负值、毫秒误传）上翻车。

真正省事的做法是：在应用层就确认好时间戳单位，并根据目标数据库选对应函数。如果SQL要跑多库，建议把转换逻辑提到代码里做（例如Python用 datetime.fromtimestamp()），SQL只存裸数值。

最容易被忽略的是时间戳来源——前端JS的 Date.now() 是毫秒，后端Go的 time.Now().Unix() 是秒，混在一起不校验单位，查出来的时间永远差1000倍。