在 Windows 95 中，文件属性表中的时间戳信息会显示当地时区的多个时间戳，即使在当时不使用该时区。例如，现在我们位于 Redmond，采用太平洋标准时间，因此 Windows 95 将显示所有与太平洋标准时间相关的时间戳。结果，对于在 7 月 4 日中午创建的文件上的时间戳，当您在冬季查看时显示创建时间为上午 11:00，因为太平洋夏令时的中午正值太平洋标准时间的上午 11:00。不过，在 7 月 4 日 Redmond 没有采用太平洋标准时间，但从技术角度分析该信息是正确的（即使从直觉上判断是错误的）。
对非夏令时边界（美国以外的地区通常称为夏令时）的此种处理方式是托管代码和非托管代码之间的显著差异。以前，非托管代码在协调世界时 (UTC) 和当地时间之间进行转换，并且当地时间基于时间转换时的当地时区，而非基于时间转换时生效的时区。原因之一就是，将时区基于转换的时间可能会导致混淆或无法转换时间。例如，在美国，将标准时间转化为夏令时，时间会前移一个小时，如从上午 2:00 到上午 3:00。记录为 2:30 a.m. 的当地时间可能没有相应 UTC 时间与之对应，因为在当地没有 2:30 a.m. 这种格式。更糟糕的是，在从夏令时转换到标准时间的过程中记录为 2:30 a.m 的当地时间会不明确，因为在此类转换过程中，时间会后退一个小时，当地时间 2:30 a.m. 出现两次。
不使用正在转换的时间选择时区还在于，在很多情况下，OS 不包含了解哪个时区在过去的某个时间生效的必要信息。适用于在标准时间和夏令时之间更改的规则由当地政府更改。此外，一直以来，一些国家/地区（如以色列和巴西）不遵循一系列可预测的规则，而是根据具体情况决定日期更改。给定过去或将来的某个时间，十分有把握地确定在该时间生效的时区非常困难，即使是将来，也不可能。（希望您可以想出有意义的解决办法，提前实现时间标准化！）
另一方面，托管代码中的 System.DateTime 类会尽力确定时间转换时生效的时区，可能会显示一些看似更正确的内容，但当在使非托管代码发生错误的不常见情况中显示时，也可能是错误的。
我们回到“发展”的主题。在 Windows 2000 中，时间戳的格式已进行细微修改，采用当前日期的昨天、今天或明天表示某个日期。例如，属性表不再采用“创建于:2009 年 2 月 14 日上午 7:00:00，星期日”，而是采用“创建于:2009 年 2 月 14 日上午 7:00:00，今天”（2 月 14 日查看时）。未做任何本质更改；只是外观调整以使之更适用。
在 Windows Vista 中，时间戳的时间部分更友好一些：如果时间和日期指当天，则以相对表示法提供时间戳的时间部分：“创建于:2009 年 2 月 14 日，今天，15 分钟之前”。
最近，在 Windows 7 中，在文件属性表常规页面上，根据在您所在位置创建文件时生效的时区显示时间戳，而不是根据当前时间，从而使属性表与托管代码显示时间戳的方式更加一致。最终，即使在冬季，您于 7 月 4 日中午创建的文件都将显示为在中午创建。此更改利用新推出的“动态时区”，允许时区的夏令时规则每年进行更改。这就允许 Windows 了解为什么在 Redmond 于 2006 年 10 月 30 日创建的文件采用太平洋标准时间，而于 2007 年 10 月 30 日创建的文件采用太平洋夏令时，原因在于美国夏令时规则更改已于 2007 年生效。
但是，请注意 Windows 随附的历史信息不会返回到 1987 年以前（当时的规则仍然不同），因此早于 1987 年的时间戳可能最终仍会转换错误。
所有这些对时间戳转换的更改的结果都相同 — 无论使用哪个版本的 Windows 查看，最后显示的值都可能相差一个小时。时间戳本身并没有更改；只是 Windows 改变了其显示方式。
Comments