如何在 1641 年“创建”一个文件？

Question

几年前，我在我们的文件服务器上偶然发现了这个文件。

我想知道一个文件怎么能说它是在 1641 年创建的？据我所知，PC 上的时间由自 1970 年 1 月 1 日以来的秒数定义。如果该指数出现故障，您可以得到 1969 年 12 月 31 日（该指数可能表示 -1），但我对此感到困惑看似随机的日期，甚至早于美利坚合众国的成立。

那么一个文件的日期怎么可能是 1641 年呢？

PS：日期是法语。Février 是二月。

Answer 1

为什么可以使用 1600 年代的日期？

Windows不像 Unix 系统那样存储文件修改时间戳。根据Windows 开发中心（强调我的）：

文件时间是一个 64 位值，表示自 1601 年 1 月 1 日上午 12:00协调世界时 (UTC)以来经过的 100 纳秒间隔数。当应用程序创建、访问和写入文件时，系统会记录文件时间。

因此，通过在此处设置错误的值，您可以轻松获取 1600 年代的日期。

当然，另一个重要的问题是：这个值是如何设置的？实际日期是多少？我认为您永远无法发现，因为这可能只是文件系统驱动程序中的计算错误。另一个答案假设日期实际上是解释为 Windows 时间戳的 Unix 时间戳，但它们实际上是按不同的时间间隔（秒与纳秒）计算的。

这与 2038 年问题有什么关系？

使用 64 位数据类型意味着 Windows（通常）不受传统 Unix 系统所具有的2038 年问题的影响，因为 Unix 最初使用的是 32 位整数，它比 Windows 的 64 位整数更早溢出已。（尽管 Unix 以秒为单位运行，Windows 以微/纳秒为单位运行。）

当然，使用旧版本的 Visual Studio 编译的 32 位程序时，Windows仍然会受到影响。

较新的 Unix 操作系统已经将数据类型扩展到 64 位，从而避免了这个问题。（实际上，由于 Unix 时间戳以秒为单位运行，因此新的环绕日期将从现在起 2920 亿年。）

可以设置的最大日期是多少？

对于好奇的人 - 以下是计算方法：

• 64 位整数中可能值的数量是2 ⁶³ – 1 = 9223372036854775807。
• 每个刻度代表 100 纳秒，即 0.1 µs 或 0.0000001 s。
• 最大时间范围是9223372036854775807 ？0.0000001 s，所以数千亿秒。
• 一小时有 3600 秒，一天有 86400 秒，一年有 365 天，所以有86400 ？365 秒 =一年31536000 秒。当然，这只是一个平均值，忽略了闰年、闰秒或未来世界末日后政权可能对剩余地球人造成的任何日历变化。
• 9223372036854775807 ? 0.0000001 秒 / 31536000 秒？29247年
• @corsiKa解释我们如何减去闰年：29247 / 365 / 4 ？20
• 所以你的最大年份是1601 + 29247 – 20 = 30828。

有些人实际上试图设置这个并在同一年提出。

Answer 2

如果你对一些猜测不觉得太糟糕，让我提供一个解释。而且我的意思不是“有人将价值设置为无意义”，这显然总是可能的:)

Unix 时间通常使用自 1970 年以来的秒数。另一方面，Windows 使用 1601 作为其起始年份。所以如果我们假设（这是一个很大的假设！）问题是两次之间的错误转换，我们可以想象应该表示的日期实际上是 2011 年的某个时间 (1970 + 41)，它被错误转换到 1640 (1601 + 41)。编辑：实际上，我在 Windows 开始的那一年犯了一个错误。实际的创建时间可能是在 2010 年，或者涉及另一个错误（一个错误在软件中很常见：D）。

鉴于今年恰好是与相关文件相关的另一个跟踪日期，我认为这是一个非常合理的解释:)

Answer 3

正如其他人所写的那样，Windows 时代是 1601-01-01 00:00。

该纪元和显示的文件时间之间的秒数是 1 266 705 294。
如果我们将其添加到 Unix 时代，我们将到达2010-02-20 23:34:54 CEST，一个星期六。这大约是上次访问日期的一年前，这使得它有些可信。所以它可能是一个针对错误时代解释的 Unix 时间戳。