此结构是一个 64 位值，表示
自 1601 年 1 月 1 日以来 100 纳秒间隔的数量。
为什么设置为“自 1601 年以来”？为什么不是 unix 时间 1970 甚至 2000？我能用如此遥远的时间日期的兼容性做些什么？
回答我自己。
ANSI 日期将 1601 年 1 月 1 日定义为第 1 天，并用作 COBOL 整数日期的来源。这个纪元是公历中前一个 400 年闰年周期的开始，该周期以 2000 年结束。您可以在维基百科的 Julian_day 条目下找到。
问问题
37240 次
4 回答
57
因为 1601 年 1 月 1 日是纪元的开始。
从Raymond Chen那里得到它：
为什么 Win32 纪元是 1601 年 1 月 1 日？
该
FILETIME结构以 1601 年 1 月 1 日以来的 100 纳秒间隔的形式记录时间。为什么选择那个日期？公历以 400 年为周期运行，1601 年是在设计 Windows NT 时处于活动状态的第一年。换句话说，选择它是为了使数学很好地得出结论。
我实际上收到了来自 Dave Cutler 的电子邮件，证实了这一点。
奖金喋喋不休
RFC4122 UUID也测量 100ns滴答，但它们从 10/15/1582 开始（而不是FILETIME1/1/1601：
Date Ticks Uuid Epoch ticks
---------------------- ------------------ ------------------
1582-10-15 -5748192000000000 0 Start of uuid epoch
1601-01-01 0 0x00146BF33E42C000 Start of Windows epoch
1899-12-30 0x014F35A9A90CC000 0x0163A19CE74F8000 Lotus 123/Excel/Access/COM zero date
1900-01-01 0x014F373BFDE04000 0x0163A32F3C230000 SQL Server zero date
1970-01-01 0x019DB1DED53E8000 0x01B21DD213814000 Unix epoch timestamp
2000-01-01 0x01BF53EB256D4000 0x01D3BFDE63B00000
2010-01-01 0x01CA8A755C6E0000 0x01DEF6689AB0C000
2020-01-01 0x01D5C03669050000 0x01EA2C29A747C000
//FILETIME eras
1972-01-21 11:43:51 PM 0x01A0000000000000 0x01B46BF33E42C000 Start of 0x01A era
1986-04-30 11:43:13 AM 0x01B0000000000000 0x01C46BF33E42C000 Start of 0x01B era
2000-08-06 11:42:36 PM 0x01C0000000000000 0x01D46BF33E42C000 Start of 0x01C era
2014-11-14 11:41:59 AM 0x01D0000000000000 0x01E46BF33E42C000 Start of 0x01D era
2029-02-20 11:41:22 PM 0x01E0000000000000 0x01F46BF33E42C000 Start of 0x01E era
2043-05-31 11:40:44 AM 0x01F0000000000000 0x02046BF33E42C000 Start of 0x01F era
//UUID eras
1968-02-11 11:43:13 AM 0x019B940CC1BD4000 0x01B0000000000000 Start of uuid 0x01B era
1982-05-20 11:42:36 PM 0x01AB940CC1BD4000 0x01C0000000000000 Start of uuid 0x01C era
1996-08-27 11:41:59 AM 0x01BB940CC1BD4000 0x01D0000000000000 Start of uuid 0x01D era
2010-12-04 11:41:22 PM 0x01CB940CC1BD4000 0x01E0000000000000 Start of uuid 0x01E era
2025-03-13 11:40:44 AM 0x01DB940CC1BD4000 0x01F0000000000000 Start of uuid 0x01F era
奖金喋喋不休
Excel 使用零日期12/30/1899以便与 Lotus 1-2-3 兼容。这也是 Excel 将 1900 年 2 月视为闰年的原因（因为 Lotus 1-2-3 的人认为是闰年）。这就是为什么March 1, 1900在 Excel 中也无法表示之前的日期。
于 2013-06-26T17:26:13.440 回答
11
嗯，1601 年 1 月 1 日是 17 世纪的第一天。摆钟是在 17 世纪发明的，可以将时间精确到 1 秒1。因此（理论上）从那个时期的现有文献中可能会引用以该精度测量的时间点。
但实际上，选择是任意的。必须有一个“时代”，并提供
时代足够远，以至于“负时间”值很少见，并且
未来的环绕时间足够远，可以在几代人之外，
任何选择都可以。
但是，嘿，如果你这么担心，给史蒂夫巴尔默写一封信2。
鉴于声称的消息来源，我倾向于相信伊恩博伊德的回答。其中的原因是它使数学更容易（用于公历闰年计算）。然而，考虑到这种简化是多么微小，以及它背后的推理多么薄弱，选择（IMO）本质上是任意的。（并不是说我是错的……）
1 - 好的......可能不是那么准确。
2 - 或萨蒂亚纳德拉。
于 2012-06-01T11:59:43.717 回答
7
这是一个务实的选择。
现代西方历法直到 1752 年才保持一致，当时英国（及其殖民地）采用了公历，自 1582 年以来，大部分天主教欧洲都采用了公历。
这是带有闰年等的现代日历，以保持 1 月 1 日与冬至一致。
那么为什么不从 1752 年 1 月 1 日开始呢？因为基本的闰年规则“如果两位数的年份可以被四整除，则它是闰年，除非四位数的世纪也能被四整除”）建立了一个 400 年的周期。第一个完整周期从 1601 年 1 月 1 日开始（至少在罗马）。
闰年和日期的计算很痛苦，因为没有从四百年周期的中途开始，所以 1600 是一个很好的开始，只要你记得 1752 年之前的任何日期都需要通过地理位置来限定，因为英国的日期是 10 天不同步。与此时的罗马日期。
于 2012-06-07T06:59:54.553 回答
4
正如已经提到的，我认为流行的答案是因为公历以 400 年为周期运行，而 1601 年是在设计 Windows NT 时处于活动状态的第一年。
1601 年 1 月 1 日是 COBOL 整数日期的起源。
它也是 ANSI 日期格式的第 1 天。
如果您根据 ISO8601 进一步推测，这是它所处的格式，在 1583 年之前，时间是基于每年 366 天的公历。也许他们只是四舍五入到下一个世纪。
于 2014-10-07T00:24:59.627 回答