MySQL的CURRENT_TIMESTAMP不带时区，PostgreSQL的天然带时区，SQL Server需用SYSDATETIMEOFFSET()；跨库无兼容写法，应优先在应用层处理或使用各库原生时区函数。
MySQL 中 CURRENT_TIMESTAMP 默认不带时区信息
MySQL 的 CURRENT_TIMESTAMP 返回的是服务器本地时间（datetime 类型），不包含时区偏移，也不受客户端时区设置影响。它本质上等价于 NOW()，底层依赖系统时区（由 system_time_zone 变量决定），但结果值本身没有 +08:00 这类标识。
如果你需要带时区的当前时间，不能直接靠 CURRENT_TIMESTAMP 输出，得手动拼接或换用其他方式。
- 查当前会话时区：执行
SELECT @@session.time_zone; - 查系统时区：执行
SELECT @@global.time_zone; - 若返回
SYSTEM，说明使用系统默认时区；若返回类似+08:00，则可结合CURRENT_TIMESTAMP构造带偏移的时间字符串
PostgreSQL 中 CURRENT_TIMESTAMP 天然带时区
PostgreSQL 的 CURRENT_TIMESTAMP 默认返回 timestamp with time zone（timestamptz）类型，值已按数据库时区（timezone 参数）转换并存储为 UTC，查询时再按当前会话时区格式化输出。
这意味着你拿到的不是“原始系统时间”，而是经过时区归一化处理的时间值，语义更严谨。
- 查看当前会话时区：
SHOW timezone; - 强制以 UTC 输出：
SELECT CURRENT_TIMESTAMP AT TIME ZONE 'UTC'; - 转为指定时区字符串（含偏移）：
SELECT TO_CHAR(CURRENT_TIMESTAMP, 'YYYY-MM-DD HH24:MI:SS.US TZ');
SQL Server 中 GETDATE() 和 SYSDATETIMEOFFSET()
SQL Server 没有标准的 CURRENT_TIMESTAMP 时区版本，CURRENT_TIMESTAMP 实际是 GETDATE() 的同义词，返回 datetime（无时区）。
真正带时区的函数是 SYSDATETIMEOFFSET()，它返回 datetimeoffset 类型，包含精确到100纳秒的时间和当前服务器时区偏移（如 2024-05-22 14:30:22.1234567 +08:00）。
-
GETDATE()和CURRENT_TIMESTAMP：仅datetime，无偏移 -
SYSDATETIMEOFFSET()：推荐用于需时区场景，值可参与时区转换（如SWITCHOFFSET、AT TIME ZONE） - 注意：
AT TIME ZONE是 SQL Server 2016+ 特性，可将datetime转为datetimeoffset，但需明确指定源时区名（如'China Standard Time'），而非简单写+08:00
跨数据库兼容写法不存在，别硬套 CURRENT_TIMESTAMP
不同数据库对 CURRENT_TIMESTAMP 的实现差异太大：MySQL 不带时区、PostgreSQL 带时区但逻辑是 timestamptz、SQL Server 则完全另起一套。试图用同一句 SQL 在多个库中获取“带时区当前时间”必然失败。
实际开发中，更可靠的做法是：在应用层获取带时区时间（如 Python 的 datetime.now(ZoneInfo("Asia/Shanghai")) 或 JS 的 new Date().toISOString()），再传入 SQL；或者在数据库侧明确使用各库的原生时区函数，不依赖别名。
最容易被忽略的一点：即使数据库返回了带偏移的时间字符串（比如用 TO_CHAR 拼出来的），它也只是文本，无法直接参与时间计算或索引查找——真有时区需求，务必用原生带时区类型（timestamptz / datetimeoffset），而不是字符串模拟。
