很多 C++ 项目一到“跨时区时间”就开始手动加减小时，但这套做法一遇到夏令时、历史规则变化就很容易出错。要把时区转换写得稳，核心思路其实很明确：用 C++20 的 std::chrono::zoned_time 处理 IANA 时区数据，把转换过程统一建立在 sys_time 这个 UTC 时间点之上，再补齐编译链接和异常兜底这两件事。
为什么要用 std::chrono::zoned_time
std::chrono::zoned_time 是 C++20 里处理时区转换最可靠的原生工具。它把 IANA 时区数据库的查找、偏移量计算以及夏令时规则都纳入了标准库语义，适合直接承担“一个时间点在不同时区下如何表示”这类需求。
相比之下，C++17 及更早版本没有原生时区支持。如果继续用 std::time_t、std::tm 再配合手工维护 TZ 规则，风险会非常高，尤其是下面两类场景：
- 夏令时切换，某些本地时间可能重复出现，或者根本不存在；
- 历史时区规则变化，不同年份的偏移量并不固定。
这也是为什么不建议用 localtime_r 或 gmtime_r 去做“手动加减小时”。那种写法只是粗暴偏移，并不是真正意义上的时区转换。
编译前先确认链接参数和时区数据库
很多人第一次用 std::chrono::zoned_time，代码本身没问题，却卡在编译或运行阶段。最常见的原因有两个：链接参数漏了，以及系统没有可用的时区数据库。
Linux 和 macOS 要注意 -ltz
在 Clang 或 GCC 环境下，漏掉 -ltz 时，通常会遇到类似下面的链接错误：
undefined reference to 'std::chrono::zoned_time<...>::zoned_time(...)'
因此，Linux/macOS 下除了确认系统安装了 tzdata，编译命令里也要把链接参数补全。
clang++ -std=c++20 -O2 main.cpp -ltz
g++ -std=c++20 -O2 main.cpp -ltz
在某些 libstdc++ 版本中，还可能涉及 -lstdc++_shared 之类的额外依赖，这一点要结合本地工具链版本判断。
Windows 默认环境通常不完整
MSVC 默认并不自带可直接使用的时区数据库支持。如果你在 Windows 上依赖这套能力，通常需要额外安装 ICU，或者改用 Howard Hinnant 的 date 库。也就是说，代码即便遵循 C++20 接口，运行环境是否具备时区数据，仍然要单独确认。
真正的关键：先落到 sys_time，再谈跨时区显示
时区转换里最容易混淆的地方，不是 API 名字，而是“时间点”和“时间表示”这两个概念。
zoned_time 在构造时，最稳妥的输入是 sys_time，也就是一个明确的 UTC 时间点。很多误用都来自把用户输入的本地字符串，例如 2024-05-20 14:30，直接当成一个已经带时区语义的值去构造 zoned_time。这样做的问题在于：字符串本身只是本地表示，不是宇宙中的唯一瞬间。
正确思路应该分两步：
- 先把本地时间解释到某个确定的源时区里；
- 再取出对应的
sys_time，交给目标时区重新显示。
下面这段代码体现的就是这个过程：先把北京时间解释清楚，再转换成纽约时间。
// 正确：把北京时间字符串转成 UTC 时间点，再转纽约
auto bj_zone = std::chrono::locate_zone("Asia/Shanghai");
auto ny_zone = std::chrono::locate_zone("America/New_York");
auto local_tp = std::chrono::local_days{2024y/5/20} + 14h + 30min;
auto zt_bj = std::chrono::zoned_time{bj_zone, local_tp};
auto ny_tp = zt_bj.get_sys_time(); // 得到对应的 UTC 时间点
auto zt_ny = std::chrono::zoned_time{ny_zone, ny_tp}; // 再用 UTC 时间点构造纽约时间
这里有个非常重要的判断标准：同一个 sys_time 在不同 zoned_time 下，显示出来的字符串可以不同，但它们代表的是同一瞬间。只要这个锚点没丢，转换就不会跑偏。
因此，实际开发里不要走“先格式化成字符串，再解析成另一个时区”的路线。所有可靠转换，都应该以 sys_time 作为中间锚点。
时区名和异常处理是线上稳定性的分水岭
另一个高频踩坑点，是对时区名格式和错误返回方式的误判。std::chrono::locate_zone() 找不到时区时，不会返回空指针，而是直接抛出异常。也就是说，只要时区名来自配置、用户输入或外部接口，就必须把异常处理补上。
IANA 时区名要用规范写法
可用名称应当是 IANA 时区名，例如：
"Asia/Shanghai""America/New_York""Europe/London"
这类名字通常带斜杠，且要使用标准命名。不能把缩写直接塞进去，例如 "PST"、"CET" 都不合法；Windows 常见的 "China Standard Time" 这类系统时区名，也不会被 locate_zone 识别。
异常要显式兜底
只要数据库缺失、时区名无效，或者部署环境不完整，运行时就可能抛出 std::runtime_error。安全做法是把定位时区的代码包在 try-catch 里，并准备好回退策略或报错信息。
try {
zone = std::chrono::locate_zone(name);
} catch (...) {
/* fallback or error */
}
如果要给前端提供合法时区列表，也可以直接遍历 std::chrono::get_tzdb().zones。这比让用户自由输入任意缩写要稳得多，也更利于校验。
写对时区转换，核心就盯住这四件事
把这类需求落到工程实践里，可以直接按下面的顺序检查：
- 语言和标准库环境是否支持 C++20 的
std::chrono::zoned_time； - Linux/macOS 是否安装
tzdata，编译时是否补了-ltz； - 转换过程是否以
sys_time为中间锚点，而不是手动加减小时； - 时区名是否采用 IANA 规范，且对
locate_zone()异常做了处理。
如果这四点都满足，绝大多数“时区转换结果不对”的问题都会提前消失。真正难的从来不是把时间显示成另一种格式，而是先分清楚：你手里拿着的是一个本地时间表示，还是一个已经确定的时间点。
