正在閱讀HFS+ 的維基百科文章，我注意到允許的日期範圍是 1904 年 1 月 1 日 – 2040 年 2 月 6 日。NTFS 的範圍是 1601 年 1 月 1 日 - 60056 年 5 月 28 日。我可以理解 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 日中午開始計算天數。 。透過使用 MJD 而不是 JD，他們能夠將當代日期放入 18 位元中，這在當時是一項重要的壯舉。看本文來自 VMS Engineering 的詳細資訊。
答案2
單獨檢查時，NTFS 的寬時間戳範圍似乎不合邏輯。但當你從大局來看時，這是完全合乎邏輯的。
作業系統所做的事情之一是提供大多數程式所需的一組功能。這使得程式設計師可以專注於他們的程序，而不是浪費時間為每個程式重寫這些通用函數。任何不提供這些功能的作業系統都不太可能成功。 Windows 和 Linux 提供了數百個這樣的函數。
Windows 包含一系列用於表示和處理日期和時間的函數。為了獲得最大的實用性，這涵蓋了盡可能廣泛的日期範圍。許多程式將這些函數用於多種目的。
NTFS 檔案系統是作為 NT 平台的一部分發布。與任何現代檔案系統一樣，它需要某種方式來儲存檔案日期戳記。從邏輯上講，設計者選擇使用與提供給應用程式相同的系統。這使開發人員的事情變得更簡單。當然，日期範圍比日期戳記所需的範圍要寬得多，但它不需要花費任何費用，也不會引起任何問題。使用日期戳記的日期範圍較受限制的不同系統是不合邏輯的。
答案3
日期（及其位元層級的格式規格）不僅用於標記文件，還用於計算和許多其他地方。例如，歷史學家可能希望在他的 Excel 欄位中包含 17 或 18 世紀的日期；或者天文學家計算這些時期的行星排列。
即使使用它的人很少，損失也可以忽略不計——如果你能使用這種格式100年、5000年或60000年，那也沒有什麼大不了；它可能無法在未來 50 年中生存。