CAST不能直接转换UNIX时间戳，需用数据库特有函数：MySQL用FROM_UNIXTIME()，PostgreSQL用TO_TIMESTAMP()，SQL Server用DATEADD()，SQLite用datetime()，且须注意秒/毫秒单位。
CAST 本身不能直接转换 UNIX 时间戳
UNIX 时间戳是整数（秒数或毫秒数），CAST 只负责类型转换（比如 INT → VARCHAR），不带日期解析逻辑。直接写 CAST(timestamp AS DATE) 会报错或返回意外结果——它不会自动识别这是“自1970-01-01起的秒数”。必须配合数据库特有的时间函数。
MySQL：用 FROM_UNIXTIME() + 格式化
MySQL 提供原生支持，最简洁可靠：
SELECT FROM_UNIXTIME(1717027200); -- 返回 '2024-05-30 00:00:00'
要只取年月日，两种常用方式：
-
DATE(FROM_UNIXTIME(1717027200))→'2024-05-30' -
FROM_UNIXTIME(1717027200, '%Y-%m-%d')→ 字符串'2024-05-30'，注意这是VARCHAR类型，不是DATE
⚠️ 注意：如果时间戳是毫秒级（如 JavaScript Date.now()），先除以 1000：FROM_UNIXTIME(1717027200000 / 1000)
PostgreSQL：用 TO_TIMESTAMP() 配合 AT TIME ZONE
PostgreSQL 没有 FROM_UNIXTIME，但 TO_TIMESTAMP() 是标准解法：
SELECT TO_TIMESTAMP(1717027200); -- 默认返回带时区的 TIMESTAMPTZ
转为无时区的日期类型，推荐显式指定时区：
-
(TO_TIMESTAMP(1717027200) AT TIME ZONE 'UTC')::DATE→2024-05-30 - 若业务在东八区，用
AT TIME ZONE 'Asia/Shanghai'，避免隐式时区转换偏差
⚠️ 错误写法：CAST(1717027200 AS DATE) 会尝试把数字 1717027200 当作“日期值”解释（如 PostgreSQL 把它当儒略日），结果完全错误。
SQL Server 和 SQLite 的处理差异
SQL Server 不支持秒级 UNIX 时间戳直转，需手动计算：
SELECT DATEADD(SECOND, 1717027200, '1970-01-01');
SQLite 则依赖 datetime() 函数：
SELECT datetime(1717027200, 'unixepoch'); -- 返回 '2024-05-30 00:00:00'
再取日期部分：date(1717027200, 'unixepoch') → '2024-05-30'
⚠️ 所有数据库中，时间戳单位（秒 vs 毫秒）必须确认清楚；混用会导致日期偏移整整 46 年（1000 倍误差）——这是最常被忽略、最难排查的问题。
