为什么要设置“自1601年”?为什么不是Unix时间1970或甚至2000年?
对于如此遥远的日期兼容性,我该怎么办? 参考:http://msdn.microsoft.com/en-us/library/aa915351
回答自己。
ANSI日期将1601年1月1日定义为第1天,并用作COBOL整数日期的起点。这个纪元是公历闰年的前400年周期的开始,该周期以2000年结束。您可以在维基百科的儒略日词条中找到相关信息。
回答自己。
ANSI日期将1601年1月1日定义为第1天,并用作COBOL整数日期的起点。这个纪元是公历闰年的前400年周期的开始,该周期以2000年结束。您可以在维基百科的儒略日词条中找到相关信息。
因为1601年1月1日是时代的开始。
引用Raymond Chen的话:
为什么Win32时代是1601年1月1日?
FILETIME
结构以自 1601 年1月1日起的100纳秒间隔形式表示时间。为什么选择这个日期?公历采用400年一个循环,而1601年是该循环在 Windows NT 设计时处于活动状态的第一年。换句话说,这个日期被选择是为了使计算更方便。
我还有Dave Cutler确认的电子邮件。
RFC4122 UUIDs也使用100ns的滴答来衡量时间,但它们从1582年10月15日开始(与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使用1899年12月30日
作为零日期,以便与Lotus 1-2-3完全兼容。这也是Excel认为1900年2月是闰年的原因(因为Lotus 1-2-3的开发人员这样认为)。这就是为什么在Excel中无法表示1900年3月1日
之前的日期。
1601年1月1日是17世纪的第一天。在17世纪发明了摆钟,允许测量时间精度达到1秒1。因此(理论上)可能会在当时的现存文献中有对测量该精度的时间点的参考。
但实际上选择是任意的。必须有一个“纪元”,只要
远古的“负时间”价值很少,
周长时间距离足够远,可以推迟几代人,
任何选择都可以。
但是,如果你非常担心这个问题,请给Steve Balmer2写信。
我倾向于相信Ian Boyd的答案,因为他声称来源可靠。其中的原因是它使得公历闰年计算变得更加容易。然而,由于这种简化非常微小,而且其背后的原因也不充分,所以选择(我认为)本质上是任意的。(并不是说它是错的...)
1 - 好吧...可能没有那么准确。
2 - 或Satya Nadella。
这是一个务实的选择。
直到1752年,英国(及其殖民地)采用了公历格里高利历法,这个现代西方日历在1582年以来已被大多数天主教欧洲国家采用。
这是一种现代日历,它包括闰年等,以保持1月1日与冬至对齐。
那么为什么不从1752年1月1日开始呢?因为基本的闰年规则“如果二位数字年份可被4整除,且四位数字世纪年份也可被4整除,则该年为闰年”,建立了一个400年的周期。第一个完整的周期始于1601年1月1日(至少在罗马)。
闰年和日期计算已经足够繁琐,而在四百年周期的中途开始还会更加复杂,所以1600年是一个相当不错的起点,只要记得在1752年之前任何日期都需要加上地理位置说明,因为此时英国的日期比罗马的晚了10天。