time_t 与 struct tm 双向转换需警惕时区陷阱：localtime 依赖系统时区，gmtime 固定返回 UTC，二者混用会导致错误；C++20 std::chrono::zoned_time 是最可靠解法，明确分离时区、时间点与日历时间。
time_t 与 struct tm 的双向转换容易忽略时区
直接用 localtime 或 gmtime 转换 time_t，看似简单，但结果依赖全局时区设置——localtime 读的是当前系统时区，gmtime 固定返回 UTC，两者不能混用后直接比较或计算差值。比如在东八区调用 localtime(&t) 得到的 tm_hour 是 14，不代表 UTC 就是 6 点，因为 tm 结构体本身不携带时区元信息。
- 若需确定性转换（如跨时区服务），别依赖
localtime，改用 C++20 的std::chrono::zoned_time，或手动加减偏移 - 老项目用 C 风格函数时，可用
timezone全局变量 +tzset()强制刷新，但该变量不可重入，多线程下必须加锁或改用localtime_r -
mktime输入struct tm时，会按本地时区解释并转成time_t；若你传的是 UTC 时间却误用mktime，结果会错 8 小时（东八区）
C++20 std::chrono::zoned_time 是最稳的解法
它把时区、时间点、日历时间三者明确分离，避免隐式转换歧义。核心是用 std::chrono::sys_time（即 UTC 时间点）和时区名构造 zoned_time，再通过 get_local_time() 或 get_sys_time() 显式取值。
using namespace std::chrono;
auto utc = sys_days{2024y/3/15} + 14h; // UTC 时间点
zoned_time zt{"Asia/Shanghai", utc}; // 绑定时区
auto local = zt.get_local_time(); // 本地时间：2024-03-15 22:00
auto back_utc = zt.get_sys_time(); // 可逆回 UTC
- 时区名必须是 IANA 数据库标准格式（如
"Asia/Shanghai"），不是"CST"或"GMT+8"这类缩写——后者不唯一且无法处理夏令时 - Windows 上需额外链接
tzdb库（如使用 Howard Hinnant 的 date 库），否则locate_zone会抛std::runtime_error - 若只做固定偏移（如强制 UTC+8），可用
fixed_offset{hours{8}}构造zoned_time，但失去 DST 自动调整能力
手动计算偏移时，别硬编码 8 小时
很多人写 utc_sec = local_sec - 8 * 3600，这在东八区非夏令时期间碰巧对，但一旦系统时区变更（如部署到欧洲服务器）、或遇到夏令时切换（如美国 EDT 是 UTC-4），结果立刻出错。真正可靠的偏移得动态查。
- Linux/macOS 下可用
strftime("%z", ...)获取当前时区偏移字符串（如"+0800"），再解析为秒数；注意该值随tm内容变化，不是固定常量 - Windows 下推荐
GetTimeZoneInformation，返回结构体含Bias（UTC 偏移分钟）和DaylightBias，需结合IsDaylightTime判断是否生效 - 用
std::put_time格式化时，%Z输出时区缩写（如 CST），%z输出数字偏移（如 +0800），后者才可用于反向计算
从字符串解析带时区的时间最易出错
像 "2024-03-15T14:00:00+08:00" 这种 ISO 8601 字符串，C++ 标准库直到 C++20 才原生支持带时区解析。此前只能靠第三方库（如 date.h）或手动切分。
立即学习“C++免费学习笔记（深入）”；
-
std::get_time不识别时区字段，遇到+08:00会解析失败或跳过，导致时间被当作本地时间误读 - 若用
strptime（POSIX），格式串需写成"%Y-%m-%dT%H:%M:%S%z"，但%z在部分旧 libc 中不支持冒号分隔（+0800可，+08:00不可） - C++20 的
std::chrono::parse支持完整 ISO 8601，但需确保编译器启用-std=c++20且标准库实现完整（GCC 13+、Clang 15+ 较稳）
时区不是标量，是规则集合；任何试图用固定数字偏移代替时区对象的操作，都在为未来某个夏令时切换日埋雷。
