最可靠方法是用std::tm→std::mktime→std::chrono::system_clock::from_time_t转换后相减；需校验mktime返回值、正确设置tm_year/tm_mon/tm_isdst，并依时区语义选择mktime或timegm。
用 std::chrono 和 std::tm 转换日期再相减最可靠
直接手算年月日差值再乘秒数极易出错（闰年、大小月、时区、夏令时），C++11 起标准库提供了更安全的路径：先将字符串或年月日转换为 std::tm，再通过 std::mktime 转成 std::time_t，最后用 std::chrono::system_clock::from_time_t 转为高精度时间点，相减即得秒数。
关键点在于：std::mktime 会自动处理本地时区和夏令时规则，而 std::chrono::system_clock::from_time_t 是唯一标准规定能无损转换的途径。别试图用 std::chrono::seconds 手动构造——time_t 的底层单位不一定是秒（虽然几乎所有实现都是）。
- 确保
std::tm的tm_year是从 1900 起算（如 2024 年填 124），tm_mon是 0 起始（1 月填 0） -
tm_isdst = -1让系统自动判断夏令时，不要硬设 0 或 1 - 若输入是字符串（如
"2024-03-15"），需用std::get_time或strptime（POSIX）解析，注意 locale 影响
遇到负秒数或结果为 0？检查 mktime 是否返回 -1
std::mktime 在输入非法日期（如 2024-02-30、1970-01-00）时返回 -1，此时转成 time_t 后再转 system_clock::time_point 会得到未定义行为，常见表现为差值恒为 0 或负得离谱。
必须显式检查：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::tm t1 = {};
t1.tm_year = 2024 - 1900;
t1.tm_mon = 2; // March
t1.tm_mday = 15;
t1.tm_hour = t1.tm_min = t1.tm_sec = 0;
t1.tm_isdst = -1;
<p>std::time_t tt1 = std::mktime(&t1);
if (tt1 == static_cast<std::time_t>(-1)) {
// 处理错误：日期无效
}
- 即使日期合法，
mktime也可能修改tm_wday、tm_yday等字段，但不影响转换结果 - 跨年计算时，不要依赖
tm_year差值 —— 2023-12-31 到 2024-01-01 相差 1 天，但年份差为 1，月份/日期却无法线性推导
需要 UTC 时间而非本地时间？用 std::timegm（非标准但广泛支持）
std::mktime 假设输入是本地时间；若你明确知道日期 A/B 是 UTC 时间（比如日志时间戳带 Z），用它会引入本地时区偏移，导致秒数偏差数小时。
POSIX 提供 std::timegm（glibc、macOS、MSVC 2015+ 均支持），它把 tm 当作 UTC 解释：
// 假设 t1 表示 UTC 时间 2024-03-15 00:00:00 std::time_t tt1_utc = std::timegm(&t1); // 注意：不是 mktime！ auto tp1 = std::chrono::system_clock::from_time_t(tt1_utc);
- Windows 上旧版本 MSVC 可能没有
timegm，可用_mkgmtime替代（加下划线前缀） - 严格跨平台项目可手动减去
std::timezone（C++20）或调用std::gmtime+mktime绕行，但复杂度陡增 - 若用 C++20，优先考虑
std::chrono::utc_clock和std::chrono::parse，但目前主流编译器支持仍有限
性能敏感场景下避免重复解析
如果需频繁计算同一日期与其他日期的差（例如批量比对日志时间），把日期 A 固定为 std::chrono::system_clock::time_point 缓存起来，每次只转换日期 B。因为 mktime 涉及时区数据库查找和闰秒表查询，开销远高于整数减法。
- 缓存
time_point比缓存time_t更安全 —— 后者在某些嵌入式平台可能只有 32 位，2038 年问题会触发未定义行为 - 若日期格式固定（如
YYYY-MM-DD HH:MM:SS），可预编译正则或手写解析函数跳过std::get_time的 locale 开销 - 注意：
system_clock::time_point的 epoch 是 unspecified（通常是 Unix epoch），但差值始终精确到纳秒，秒数取整用duration_cast<seconds>即可
实际最难的部分不是计算本身，而是确认输入日期的时区语义和验证解析结果是否真被 mktime 接受——很多 bug 都藏在看似合法但被 quietly normalized 的日期里，比如 2024-02-29 在非闰年会被改成 3 月 1 日。
