纽约的一个秋日清晨，01:30出现过两次。
这是历史样例，不是真实会议，也不预测未来政策。脚本用已安装时区数据库检查America/New_York的2024年11月3日。两个合法本地时间都显示01:30，却分别对应UTC的05:30和06:30。同一钟面背后藏着一小时差距。
要确定一个时刻，本地时间需要足够的上下文。
标签只是地址的一部分
本地日期和钟点描述一个地区如何给时刻命名，UTC提供跨地区比较的共同参考。偏移量说明某个本地表示与参考时间怎样转换。本例重复时段里，适用偏移改变了，钟点标签却重复。
第一次01:30的偏移是UTC−04:00，第二次为UTC−05:00。带上偏移后，两个时间戳就不同了。它们都符合已安装的历史规则；只保存“01:30”，就丢掉了区分两者的信息。
一个额外标记消除歧义
Python的zoneinfo结合datetime的fold属性区分重复本地时间。样例先创建fold=0的01:30，再保留同一本地字段改为fold=1。在这次转换中，它们分别选择较早与较晚的一次，转换UTC后得到05:30和06:30。
再把两个UTC时刻转回纽约，小时和分钟相同，fold却仍不同。这种往返检验说明它们确实代表两个时刻，而不只是同一时刻的两种显示格式。
经过多久，要在一致的时间线上算
两个UTC时刻相减得到3,600秒，这是本文报告的实际间隔。单凭本地钟面看不出来。图中只采样几个UTC时刻，连线只是阅读辅助，不表示两次01:30之间钟真的停止了。
日历运算和经过时长回答不同问题。跨越偏移转换时，“明天同一本地时间”未必是“24小时后”。定期本地预约和固定时长计时器需要不同规则。本实验没有建立二者，但区别解释了软件为何不能只收一个小时字段。
偏移量不等于时区
固定−04:00只描述一种到UTC的换算；America/New_York则指一组历史和预设民用时间规则。两者相关，但不可互换。把同一偏移用于所有日期，会抹掉本例的重要转换。
规则以数据库维护，因为主管机构可能修改它们。安装的数据标记为2026b，本例只用它评估指定历史日期。版本号是计算来源记录，不保证无需更新就能永远正确安排未来日程。
明确询问，胜过悄悄猜测
本地时间有歧义时，系统需要明确规则选择或询问用户要哪一次。春季向前拨钟又有另一类问题：某些本地标签根本不会发生。这里没有测试这种情况，也不应把人为处理策略伪装成自动的数学答案。
记录过去事件时，保留无歧义时刻及必要本地背景有助解释；安排未来本地日程时，则应保留时区名称和墙上时钟规则。没有一套存储方式适合所有任务，但如果删掉字段会让两个时刻看起来一样，那字段很可能不可少。