构造std::chrono/date::zoned_time的场景适用性及时间计算疑问

首先明确：2023年1月10日22:15 并不总是等同于 2023年1月10日加上22小时15分钟，具体差异取决于时区规则、闰秒和tzdata更新这些因素，下面分场景说明：

1. 常规时区场景（无DST切换、无闰秒） #

在没有夏令时切换、也不涉及闰秒的时区里，这两种方式的结果通常一致。比如UTC时区下，日期加固定时分的计算和直接指定时分的zoned_time等价，因为UTC的时间流逝严格按每小时3600秒、每分钟60秒推进。

2. 夏令时（DST）切换场景 #

如果目标时区存在夏令时切换，两种方式可能产生完全不同的结果：

• 假设某时区在3月12日凌晨2点将时钟拨快1小时到3点，那么"3月12日2:15"这个时间点不存在。直接构造zoned_time指向该时间，库会按规则自动调整（比如映射到3:15）；而"3月12日00:00加上2小时15分钟"的计算结果也是3:15，此时两者一致。
• 反过来，夏令时结束时（比如11月5日凌晨2点拨回1小时到1点），"11月5日1:15"会出现两次。直接指定该时间的zoned_time默认取第一次出现的时间；"11月5日00:00加上1小时15分钟"也指向第一次的1:15，结果一致，但如果是"11月5日02:00减去45分钟"，会指向第二次的1:15，和直接指定的结果不同。

3. 闰秒场景 #

闰秒是为协调UTC和地球自转时间，在特定日期的最后一分钟增加或减少1秒（比如2022年12月31日23:59:60）：

• 直接指定"2022年12月31日23:59:60"的zoned_time（UTC时区），C++20及以后标准允许处理闰秒，但部分编译器/库可能未完全支持。
• 而"2022年12月31日00:00加上23小时59分钟60秒"的累加方式，若库支持闰秒，结果对应闰秒时刻；若不支持，可能自动调整到下一秒（2023年1月1日00:00:00），此时两种方式结果会出现差异。

4. tzdata更新的影响 #

tzdata是时区规则数据库，当地区时区规则变更（比如政府调整夏令时时间、变更时区偏移），更新tzdata后，同一个日期时间字符串对应的实际UTC时间会变化：

• 直接构造zoned_time时，库会用最新的tzdata规则解析日期时间；
• 日期加时分的累加方式基于当前时区偏移计算，若tzdata更新导致该日期的时区偏移变化，累加结果对应的UTC时间就会和直接指定日期时间的结果不同。

总结建议 #

• 若业务需要对应日历上的明确时分（比如用户输入的"2023-01-10 22:15"），直接用日期时间构造zoned_time更可靠，它会严格遵循时区的日历规则。
• 若为计算时间间隔后的结果（比如"某事件发生后22小时15分钟"），用时间点累加的方式更合适。
• 涉及闰秒的场景，优先使用支持闰秒的std::chrono实现（比如libstdc++最新版本），并明确区分"日历时间"和"时间间隔累加"的语义。

内容的提问来源于stack exchange，提问作者HumbleProgrammer