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），而不是字符串模拟。