这绝对是特性而非Bug——而且你的分析方向完全正确！

核心原因拆解 #

• 夏令时（DST）切换时，系统的本地时区偏移会调整±1小时。Windows和Office系列软件（包括Word）显示的文件修改时间，是把文件存储的UTC时间戳转换为本地时区后的结果。当夏令时切换，本地时区偏移变了，所有文件的显示修改时间自然会跟着偏移1小时，并非微软“重置”了文档的修改日期。
• 这种批量偏移是正常现象：所有依赖本地时区显示时间戳的文件（不止Word）都会出现这个情况，本质是时区转换逻辑的正常工作，不是文件元数据被篡改。

关于后续出现周期 #

你的推测没错——夏令时通常每年春秋各切换一次，间隔约半年，所以半年后反向切换时，会再次出现类似的时间显示偏移（只是方向相反，比如这次延后1小时，下次提前1小时）。

检测程序运行时长异常的原因 #

你提到的每日检测程序运行时长变长，大概率是因为程序是基于本地显示的修改时间做变更检测的。当所有文档的显示时间集体跳变1小时，程序会误判为所有文档都发生了修改，导致需要扫描对比的内容暴增，运行时间自然拉长。

如果这个程序是你自己开发的，建议调整逻辑：读取文件的原始UTC时间戳进行对比，而非本地转换后的时间，这样就能彻底规避夏令时切换带来的干扰。

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