不能直接用 localtime 处理 UTC 时间戳，因为它将 time_t 误当作本地时间解析；正确做法是用 gmtime 或设置 TZ 环境变量后调用 localtime_r，或使用 C++20 的 chrono 时区支持。
为什么不能直接用 localtime 处理 UTC 时间戳
localtime 会把传入的 time_t 当作本地时区时间来解析，而不是 UTC。如果你有一个 UTC 时间戳（比如 1717027200，对应 2024-05-30 00:00:00 UTC），直接喂给 localtime，它会错误地当成“本地时区的 2024-05-30 00:00:00”，再转成 struct tm —— 结果比真实本地时间快或慢若干小时。
正确做法是先用 gmtime 得到 UTC 对应的 struct tm，再手动加上本地时区偏移（含夏令时判断）；或者更稳妥地：用 time_t 构造 UTC 时间点，再调用平台支持的时区感知转换函数。
Linux/macOS 上用 localtime_r + tzset 配合时区环境变量
只要确保 TZ 环境变量已设置（如 TZ=Asia/Shanghai），localtime_r 就能将 UTC 时间戳正确转为本地 struct tm：
setenv("TZ", "Asia/Shanghai", 1);
tzset();
time_t utc_ts = 1717027200; // 2024-05-30 00:00:00 UTC
struct tm local_tm;
localtime_r(&utc_ts, &local_tm); // ✅ 此时 local_tm 是北京时间 2024-05-30 08:00:00
-
tzset()必须在setenv后调用，否则localtime_r仍用旧时区缓存 - 线程安全：优先用
localtime_r而非localtime - 注意：修改
TZ会影响整个进程，多线程下需同步控制
跨平台可移植方案：用 std::chrono + std::format（C++20）
C++20 的 <chrono> 提供了明确的时区语义，避免依赖 C 库时区状态：
立即学习“C++免费学习笔记（深入）”；
using namespace std::chrono;
auto utc_tp = sys_seconds{seconds{1717027200}}; // UTC 时间点
auto local_tp = utc_tp + current_zone()->get_offset(utc_tp); // 自动加本地偏移
std::tm local_tm = *std::gmtime(&local_tp.time_since_epoch().count());
- 需要链接
-ltz（Linux）或启用_ENABLE_EXTENDED_ALIGNED_STORAGE（MSVC） -
current_zone()返回当前系统时区，自动处理夏令时 - 若无法用 C++20，退回到
gmtime+ 手动加timezone/altzone偏移（但不推荐：这两个变量不可靠，且无夏令时上下文）
Windows 上必须绕过 _tzset 的坑
Windows 的 _putenv("TZ=...") 和 _tzset() 仅影响 CRT 内部时区缓存，且 localtime_s 不保证读取最新值。更可靠的方式是：
- 用
FileTimeToLocalFileTime+FileTimeToSystemTime（需先把time_t转为FILETIME） - 或使用 Windows API
GetTimeZoneInformationForYear获取指定年份的偏移，再手动修正gmtime结果 - 避免依赖
_timezone或_daylight：它们只反映进程启动时的时区，且不更新
真正麻烦的不是转换逻辑，而是时区规则本身 —— 比如 2024 年中国不用夏令时，但哈萨克斯坦部分区域用；struct tm 里 tm_isdst 字段是否置 1，得查系统数据库，不是简单加 3600 秒就能搞定的。
