不会直接出错，但用错方式就会：system_clock::time_point 基于 UTC，本身不受夏令时影响；问题出在将 time_point 转为本地时间后手动加减小时（如localtime+hours(24)），导致 DST 切换日出现跳过或重复小时；正确做法是用 zoned_time 或 date 库按日历日（而非固定秒数）递进。
夏令时切换会让 std::chrono::system_clock::time_point 计算出错吗？
不会直接出错，但用错方式就会——std::chrono 本身不处理时区或夏令时，它只管 UTC 时间戳。真正出问题的地方是：你把 time_t 或 system_clock::time_point 直接转成本地时间（比如用 localtime() 或 std::put_time），再手动加减小时数，结果在 DST 切换日（如 3 月第二个周日、11 月第一个周日）出现 1 小时偏差或重复/跳过时间。
为什么 std::chrono::hours(24) 不等于“一天”？
因为“一天”在本地时区语义下可能是 23、24 或 25 小时——取决于 DST 开启/关闭当天的偏移变化。而 std::chrono::hours(24) 是严格的 24×3600 秒，和日历日无关。
- 想表示“日历上后一天同一时刻”，必须走时区转换流程，不能靠加
hours(24) -
std::chrono::duration_cast<:chrono::hours>(tp2 - tp1)</:chrono::hours>在跨 DST 边界时会给出正确秒数差，但这个差值不等于“本地显示的小时数差” - 例如：3 月10日 02:00 美国东部时间（ET）→ 03:00，实际只过了 1 小时，但如果你按“加 24 小时”算，会跳到 3 月11日 03:00，漏掉 02:00–03:00 这个“不存在”的区间
怎么安全地做“今天 9 点 + 1 天”这类操作？
别绕开时区库。C++20 的 <chrono> 提供了 zoned_time 和 sys_days，但需搭配 IANA 时区数据（如 "America/New_York"）。若用 C++17 或更早，推荐用 Howard Hinnant 的 date 库（已并入 C++20）。
示例（C++20）：
立即学习“C++免费学习笔记（深入）”；
#include <chrono>
#include <iostream>
<p>using namespace std::chrono;</p><p>auto today_9am = zoned_time{"America/New_York",
local_days{year{2024}/March/10} + hours{9}};
auto tomorrow_9am = today_9am.get_local_time() + days{1}; // 注意：这里仍是本地时间加天数
// 更稳妥写法：
auto tomorrow_9am_v2 = zoned_time{"America/New_York",
local_days{year{2024}/March/10} + days{1} + hours{9}};- 用
local_days+days{1}表示日历日递进，不是时间戳加 86400 秒 -
zoned_time构造时自动处理 DST 偏移查找，避免手动调localtime_r导致的线程不安全或缓存失效 - 切忌混用：
system_clock::now() + hours(24)→zoned_time→get_local_time()，这种链式转换可能因中间步骤未对齐时区而引入误差
Windows 上用 GetLocalTime / SystemTimeToTzSpecificLocalTime 安全吗？
不安全。这两个 API 依赖系统当前时区设置，且 SystemTimeToTzSpecificLocalTime 不支持指定任意 IANA 时区（只认注册表里那个“当前时区”），也无法回溯历史 DST 规则（比如 2007 年前美国 DST 起止日不同）。遇到跨年计算或服务部署在多个时区机器上时，结果不可靠。
- Windows 10/11 支持通过
DynamicTimeZoneInformation获取当前偏移，但仍无法解决“某年某月某日某时是否 DST”这一核心判定问题 - 如果必须用 WinAPI，至少用
GetTimeZoneInformationForYear（Win8+），传入具体年份和时区 ID（如L"Eastern Standard Time"），但它不支持所有 IANA 名称，且规则更新滞后于 IANA 数据 - 真正跨平台、可验证的方案，还是得靠外部时区数据库（如 date 库自带的编译时嵌入数据）
DST 切换不是边界情况，而是每年固定发生两次的确定性事件；处理它的关键不是“避开”，而是承认本地时间本质是带上下文的标签——同一个 time_point 在不同时区、不同年份，映射到本地字符串的结果可能完全不同。漏掉这一点，任何“加减小时”的直觉操作都容易翻车。
