此结构是一个 64 位值,表示
自 1601 年 1 月 1 日以来 100 纳秒间隔的数量。
为什么设置为“自 1601 年以来”?为什么不是 unix 时间 1970 甚至 2000?我能用如此遥远的时间日期的兼容性做些什么?
回答我自己。
ANSI 日期将 1601 年 1 月 1 日定义为第 1 天,并用作 COBOL 整数日期的来源。这个纪元是公历中前一个 400 年闰年周期的开始,该周期以 2000 年结束。您可以在维基百科的 Julian_day 条目下找到。
此结构是一个 64 位值,表示
自 1601 年 1 月 1 日以来 100 纳秒间隔的数量。
为什么设置为“自 1601 年以来”?为什么不是 unix 时间 1970 甚至 2000?我能用如此遥远的时间日期的兼容性做些什么?
回答我自己。
ANSI 日期将 1601 年 1 月 1 日定义为第 1 天,并用作 COBOL 整数日期的来源。这个纪元是公历中前一个 400 年闰年周期的开始,该周期以 2000 年结束。您可以在维基百科的 Julian_day 条目下找到。
因为 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 开始(而不是FILETIME
1/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 中也无法表示之前的日期。
嗯,1601 年 1 月 1 日是 17 世纪的第一天。摆钟是在 17 世纪发明的,可以将时间精确到 1 秒1。因此(理论上)从那个时期的现有文献中可能会引用以该精度测量的时间点。
但实际上,选择是任意的。必须有一个“时代”,并提供
时代足够远,以至于“负时间”值很少见,并且
未来的环绕时间足够远,可以在几代人之外,
任何选择都可以。
但是,嘿,如果你这么担心,给史蒂夫巴尔默写一封信2。
鉴于声称的消息来源,我倾向于相信伊恩博伊德的回答。其中的原因是它使数学更容易(用于公历闰年计算)。然而,考虑到这种简化是多么微小,以及它背后的推理多么薄弱,选择(IMO)本质上是任意的。(并不是说我是错的……)
1 - 好的......可能不是那么准确。
2 - 或萨蒂亚纳德拉。
这是一个务实的选择。
现代西方历法直到 1752 年才保持一致,当时英国(及其殖民地)采用了公历,自 1582 年以来,大部分天主教欧洲都采用了公历。
这是带有闰年等的现代日历,以保持 1 月 1 日与冬至一致。
那么为什么不从 1752 年 1 月 1 日开始呢?因为基本的闰年规则“如果两位数的年份可以被四整除,则它是闰年,除非四位数的世纪也能被四整除”)建立了一个 400 年的周期。第一个完整周期从 1601 年 1 月 1 日开始(至少在罗马)。
闰年和日期的计算很痛苦,因为没有从四百年周期的中途开始,所以 1600 是一个很好的开始,只要你记得 1752 年之前的任何日期都需要通过地理位置来限定,因为英国的日期是 10 天不同步。与此时的罗马日期。
正如已经提到的,我认为流行的答案是因为公历以 400 年为周期运行,而 1601 年是在设计 Windows NT 时处于活动状态的第一年。
1601 年 1 月 1 日是 COBOL 整数日期的起源。
它也是 ANSI 日期格式的第 1 天。
如果您根据 ISO8601 进一步推测,这是它所处的格式,在 1583 年之前,时间是基于每年 366 天的公历。也许他们只是四舍五入到下一个世纪。