mktime 返回 -1 的常见原因是 tm_isdst 未设为 -1；必须显式设置 tm_isdst = -1 才能自动推断夏令时，否则在时区切换瞬间可能失败。
UTC 时间加偏移量后转本地 struct tm 为什么 mktime 返回 -1？
常见原因是传入的 struct tm 中 tm_isdst 字段未显式设为 -1。C++ 标准库的 mktime() 在 tm_isdst == -1 时才会自动推断夏令时；若误设为 0 或 1，且该时间在系统时区不存在（如夏令时切换瞬间），就可能返回 -1。
实操建议：
- 手动计算 UTC 偏移后，务必用
memset(&tm, 0, sizeof(tm))初始化再赋值，避免残留垃圾值 -
tm.tm_isdst = -1必须显式写，不能省略 - 偏移量单位是秒，注意正负：东八区为
+28800，西五区为-18000 - 验证输入时间是否合法（如
tm.tm_mon范围是 0–11，tm.tm_mday是 1–31）
用 time_t 直接加减偏移量再转 struct tm 安不安全？
安全，但仅限于“纯数值偏移”，不涉及时区规则变化（如历史夏令时调整、闰秒）。time_t 是自纪元以来的秒数，加减整数偏移是原子操作，不会触发时区逻辑。
实操建议：
- 先用
gmtime_r()（Linux/macOS）或_gmtime64_s()（Windows）把原始 UTC 时间转为struct tm - 转成
time_t后加偏移：time_t local_time = utc_time + offset_sec - 再用
localtime_r()转回struct tm—— 此时结果已按本地时区规则生效（含 DST 判断） - 若需严格按固定偏移（无视 DST），跳过
localtime_r，直接用gmtime_r解析加偏后的time_t，它仍视为 UTC 时间输出
跨平台处理时区偏移要注意哪些兼容性问题？
Windows 的 CRT 对 tm.tm_gmtoff 和 tm.tm_zone 不支持（这些是 GNU 扩展），而 Linux/macOS 下 localtime_r 可能填充它们。依赖这些字段会导致 Windows 编译失败或运行时未定义行为。
实操建议：
- 不要读写
tm.tm_gmtoff或tm.tm_zone，除非明确限定平台并启用 GNU 扩展 - 获取当前时区偏移应调用
_get_timezone()（Windows）或timezone全局变量（POSIX，需extern long timezone） - 更可靠的方式：用
time(nullptr)获取当前时间，分别调用gmtime_r和localtime_r，对比两者tm_hour差值算出小时偏移 - 注意 Windows 的
_tzset()必须在使用时区函数前调用，否则可能返回错误偏移
std::chrono::system_clock::from_time_t 与偏移量结合是否推荐？
不推荐直接用于带偏移的转换。因为 system_clock::from_time_t 输入仍是 POSIX time_t（即 UTC 秒数），加偏移后再转成 time_point 并不改变其语义 —— 它仍是某个 UTC 瞬间，只是数值变了。真正需要的是将该瞬间解释为某一时区的时间，而非修改时间本身。
实操建议：
- 用
std::chrono::seconds(offset_sec)构造偏移量，配合std::chrono::time_point进行算术运算没问题 - 但最终要输出“北京时间 2024-06-15 14:30”这类带时区语义的结果，必须借助
std::chrono::zoned_time（C++20）或第三方库（如 Howard Hinnant’s date） - C++20 前，老老实实用
time_t+localtime_r最稳妥 - 若用 C++20，优先写
zoned_time{locate_zone("Asia/Shanghai"), sys_time{utc_tp}}，而非手动加秒数
偏移量计算本身很简单，真正容易出错的是对 tm_isdst 的忽略、跨平台字段误用，以及混淆“时间点偏移”和“时区语义转换”。尤其在嵌入式或 Windows 环境下，localtime_r 行为差异比想象中更大。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
