getdate()返回服务器本地时区时间，getutcdate()返回对应utc时间；二者同为datetime类型，但值因时区偏移而不同，且均依赖服务器时钟精度与ntp校准状态。
GETUTCDATE 返回的是 SQL Server 实例所在服务器的 UTC 时间，不是“统一标准时间”的魔法开关——它依赖服务器时钟是否已校准到 NTP，且不自动处理夏令时或时区偏移。
GETUTCDATE 和 GETDATE 的核心区别在哪？
两者都返回 datetime 类型，但：
• GETDATE() 返回服务器本地时区时间（受 Windows 系统时区设置影响）
• GETUTCDATE() 返回服务器当前 UTC 时间（本质是 GETDATE() 减去系统时区偏移量）
• 二者值在非 UTC 时区服务器上必然不同，差值就是该服务器的时区偏移（如东八区为 +08:00）
• 如果服务器时钟不准，GETUTCDATE() 也不准——它不联网校时，只是本地计算
为什么在跨时区应用中仍可能出错？
常见误用场景：
• 把 GETUTCDATE() 存入 datetime 字段后，前端按用户本地时区直接渲染，却没做任何转换逻辑 → 时间显示错 8 小时
• 应用层和数据库层混用 GETDATE() 与 GETUTCDATE()，导致日志时间戳无法对齐
• 使用 datetime 而非 datetime2 或 datetimeoffset，丢失精度和时区上下文
• 在 Always On 可用性组中，各副本服务器时钟未同步，GETUTCDATE() 结果出现毫秒级偏差
安全使用 GETUTCDATE 的实操建议
• 始终用 datetime2(7) 存储，避免 datetime 的 3.33ms 精度缺陷
• 若需保留时区信息，改用 datetimeoffset 并显式指定偏移：SYSDATETIMEOFFSET() 或 TODATETIMEOFFSET(GETUTCDATE(), '+00:00')
• 避免在触发器或默认约束中直接写 GETUTCDATE() —— 它不支持内联函数参数，且无法被查询优化器有效预估
• 检查服务器是否启用 NTP 同步：net time /querysntp（Windows）或 timedatectl status（Linux 上 SQL Server 2019+）
• 对比 GETUTCDATE() 与权威 UTC 时间源（如 time.windows.com），偏差 > 500ms 应告警
真正麻烦的不是函数怎么调，而是你是否清楚每一行时间数据从哪来、往哪去、中间有没有隐式转换或时区抹除。尤其当 datetime 列被 ORM 自动生成、又没配时区处理策略时，问题会藏得特别深。
