答案1
为什么有可能是 17 世纪的日期?
Windows 不存储文件修改时间戳就像 Unix 系统一样. 根据Windows 开发人员中心(重点是我的):
文件时间是一个 64 位值,表示 100 纳秒的数量自 1601 年 1 月 1 日凌晨 12:00 以来的时间间隔协调世界时 (UTC)。系统会记录应用程序创建、访问和写入文件时的文件时间。
因此,通过在此处设置错误的值,您可以轻松获取 1600 年代的日期。
当然,另一个重要的问题是:这个值是如何设置的?实际日期是什么?我想你永远无法找到答案,因为这可能只是文件系统驱动程序中的计算错误。另一个答案假设该日期实际上是一个被解释为 Windows 时间戳的 Unix 时间戳,但它们实际上是按照不同的间隔(秒与纳秒)计算的。
这与 2038 年问题有何关系?
使用 64 位数据类型意味着 Windows(通常)不会受到2038 年问题传统 Unix 系统没有这种功能,因为 Unix 最初使用的是 32 位整数,它比 Windows 的 64 位整数溢出更快。(尽管 Unix 以秒为单位运行,而 Windows 以微秒/纳秒为单位运行。)
视窗仍然受到影响当然,当使用用旧版本 Visual Studio 编译的 32 位程序时。
较新的 Unix 操作系统已经扩大将数据类型改为 64 位,这样就避免了这个问题。(事实上,由于 Unix 时间戳以秒为单位,新的回溯日期将是 2920 亿年后。)
可以设置的最大日期是多少?
对于那些好奇的人来说,计算方法如下:
- 这64 位整数中可能值的数量是2 63 - 1 = 9223372036854775807。
- 每个刻度代表 100 纳秒,即 0.1 µs 或 0.0000001 s。
- 最大时间范围为9223372036854775807 ⨉ 0.0000001 秒,所以是数千亿秒。
- 一小时有 3600 秒,一天有 86400 秒,一年有 365 天,所以86400 ⨉ 365 秒 = 31536000 秒一年。当然,这只是一个平均值,忽略了闰年、闰秒,或未来后世界末日制度可能对地球上剩余的人们施加的任何日历变化。
- 9223372036854775807 ⨉ 0.0000001 秒 / 31536000 秒 ≈ 29247 年
@corsiKa
解释如何减去闰年:29247 / 365 / 4 ≈ 20- 所以你的最长年份是1601 + 29247 - 20 = 30828。
有些人实际上尝试设置这个并提出了同一年。
答案2
如果您不介意猜测,请让我解释一下。我的意思不是“有人将值设置为无意义的”,这显然总是有可能的 :)
Unix 时间通常使用自 1970 年以来的秒数。而 Windows 则使用 1601 作为起始年份。因此,如果我们假设(这是一个很大的假设!)问题在于两个时间之间的错误转换,我们可以想象应该表示的日期实际上是2011 年的某个时间(1970 + 41),而它被错误地转换为 1640 年(1601 + 41)。编辑:实际上,我在 Windows 起始年份上犯了一个错误。实际创建时间可能是 2010 年,或者涉及其他错误(软件中差一错误非常常见 :D)。
考虑到今年恰好是与该文件相关的另一个跟踪日期,我认为这是一个非常合理的解释:)
答案3
正如其他人所写,Windows 纪元为 1601-01-01 00:00。
该纪元与所显示的文件时间之间的秒数,为 1 266 705 294。
如果我们将其添加到 Unix 纪元中,我们得到2010-02-20 23:34:54 中欧夏令时,星期六。这比上次访问日期早了大约一年,因此这有点可信。因此,这可能是根据错误的纪元解释的 Unix 时间戳。
答案4
对于这类问题,Raymond Chen 的博客通常有答案摘自 2009 年 3 月 6 日的“为什么 Win32 纪元是 1601 年 1 月 1 日?”条目:
该
FILETIME
结构以 100 纳秒间隔的形式记录自 1601 年 1 月 1 日以来的时间。为什么选择这个日期?公历以 400 年为一个周期,而 1601 年正是 Windows NT 设计时采用的该周期的第一年。换句话说,选择这个年份是为了让数学计算结果更准确。
我确实收到了 Dave Cutler 发来的电子邮件来确认此事。