阅读HFS+ 的维基百科文章，我注意到允许的日期范围是 1904 年 1 月 1 日 - 2040 年 2 月 6 日。同样，NTFS 范围是 1601 年 1 月 1 日 – 60056 年 5 月 28 日。在我看来，这简直是荒谬的，因为我无法想象任何文件需要修改/创建日期设置在 1600 年代或 1900 年代的情况。我可以理解 Unix 时间戳纪元，因为在 70 年代、80 年代等创建/修改文件是合理的，但将这些时间戳的纪元设置在过去这么久远似乎不合逻辑。
答案1
不仅仅是 NTFS；Windows 内部计时使用相同的时间格式和相同的纪元开始时间。
他们知道他们想要一个 64 位二进制时间值，因为原始的 Unix 32 位值已经被认为是死胡同（这些计数器将在 2038 年结束），并且 64 位时间值已经在 VMS 中使用。64 位可以计算大约 180 亿亿个不同的时间值。实际上，只有 90 亿亿个，因为设置了高位的时间值在 Windows 中具有不同的含义（就像在 VMS 中一样）。因此，我们实际上“只有”63 位来计算日期和时间。
32 位 Unix 时间仅以秒为单位，而 Windows 时间戳以 100 纳秒为增量计算。因此，时间值 1 表示 1601 年 1 月 1 日午夜过后 100 纳秒。
但为什么要选择这样一个“历史性”日期呢？
首先，它确实使星期几和类似的计算变得容易一些，因为那是最早的 400 年周期的第一年，其中包括任何类型的电子计算机。有一些非常权威的支持是因为。
然而，我不得不说，在现代计算的背景下，应对不同起始年份所需的额外计算能力在背景下会非常小。
1601 年 1 月 1 日恰好也是 ANSI 日期的计算日期。因此，“Windows 日期”与“ANSI 日期”是相同的日期数字，这使得在各个地方的事情变得稍微简单一些。
它也被标准化为公历的“元年”（尽管当时该日历并未在所有地方采用）。
但是，出于实际工作原因，请考虑：此日期/时间格式允许历史日期/时间与当前日期/时间一起在数据库中表示，使用相同的格式。例如，家谱数据库可以存储您祖先的出生和死亡日期，可追溯到 400 多年前，这比大多数此类记录以可靠形式存在的时间要长得多。
将此时间延长至更早（比如从公元 1201 年甚至 1 年开始）是没有意义的，因为有些国家从 1582 年开始实行儒略历到公历的转换，一直持续到 1926 年（具体取决于您所在的国家/地区）。以 ANSI 时间格式记录的所有日期，以及以 Windows“二进制”时间格式记录的所有日期均假定为公历。
顺便说一句，VMS 使用类似的方案，但其基准时间是 1858 年 11 月 17 日。这是史密森天体物理天文台选择的标准，作为卫星跟踪的“基准日期”；这与天文学家早期使用的原始儒略日方案有关，该方案计算自公元前 4713 年 1 月 1 日中午以来的天数。根据此方案，1858 年 11 月 17 日等于修正儒略日数 2,400,000。通过使用 MJD 而不是 JD，他们能够将当代日期压缩到仅 18 位，这在当时是一项重要成就。参见本文详情请咨询 VMS Engineering。
答案2
单独检查时，NTFS 的宽时间戳范围似乎不合逻辑。但从整体来看，这是完全合乎逻辑的。
操作系统所做的一件事是提供一组大多数程序都需要的函数。这样程序员就可以专注于他们的程序，而不是浪费时间为每个程序重写这些常用函数。任何不提供这些功能的操作系统都不太可能成功。Windows 和 Linux 提供了数百个这样的功能。
Windows 包含一系列用于表示和处理日期和时间的函数。为了发挥最大作用，这些函数尽可能涵盖广泛的日期范围。许多程序将这些函数用于各种用途。
NTFS 文件系统是作为 NT 平台的一部分发布的。与任何现代文件系统一样，它需要某种方式来存储文件日期戳。从逻辑上讲，设计人员选择使用与提供给应用程序的系统相同的系统。这让开发人员的工作变得更简单。当然，日期范围比日期戳所需的范围要宽得多，但它不花费任何成本，也不会造成任何问题。使用日期戳日期范围更受限制的其他系统是不合逻辑的。
答案3
日期（及其位级别的格式规范）不仅用于标记文件，还用于计算和许多其他地方。例如，历史学家可能希望在他的 Excel 列中记录 17 世纪或 18 世纪的日期；或者天文学家计算这些时期的行星排列。
即使使用它的人很少，损失也是可以忽略不计的——如果你能使用这种格式 100 年、5000 年或 60000 年，那也没关系；它可能在接下来的 50 年内无法存活下来。