この構造体は、1601 年 1 月 1 日以降の 100 ナノ秒間隔の数を表す 64 ビット値です。
なぜ「1601年以来」に設定されているのですか? 1970 年や 2000 年の UNIX 時間ではないのはなぜですか? そんなに遠い時代の日付の互換性で何ができますか?
自分に答える。
ANSI Date は 1601 年 1 月 1 日を 1 日として定義し、COBOL 整数日付の起点として使用されます。このエポックは、2000 年で終了したグレゴリオ暦の閏年の 400 年サイクルの始まりです。ウィキペディアの Julian_day エントリの下で見つけることができます。
1601 年 1 月 1 日が時代の始まりだったからです。
レイモンド・チェンからそれを取ります：
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/1899Lotus 1-2-3 とのバグごとの互換性を維持するために、ゼロの日付を使用しています。これは、Excel が 1900 年 2 月をうるう年と見なす理由でもあります (Lotus 1-2-3 の担当者がうるう年だと考えていたためです)。March 1, 1900これが、Excel で以前の日付を表すことも不可能な理由です。
さて、1601 年 1 月 1 日は 17 世紀の最初の日でした。また、振り子時計は 17 世紀に発明され、1 秒の精度で時間を測定できるようになりました1。したがって、（理論的には）その時期からその正確さで測定された時点までの文献が現存する文献に記載されている可能性があります。
しかし実際には、その選択は恣意的です。「エポック」があり、提供されている必要があります
エポックが十分に遡っており、「負の時間」の値はほとんどありません。
ラップアラウンド時間は、数世代離れているほど十分に未来です。
どんな選択でも構いません。
でもねえ、そんなに心配なら、スティーブ・バルマーに手紙を送ってください2 .
主張された情報源を考えると、Ian Boyd の答えを信じる傾向があります。その理由は、数学が簡単になるためです (グレゴリオ暦の閏年の計算)。ただし、その単純化がいかに小さいか、およびその背後にある推論がいかに弱いかを考えると、選択は (IMO) 基本的に恣意的です。（それが間違っていると言っているわけではありません...）
1 - OK ... おそらくそれほど正確ではありません。
2 - またはサティア・ナデラ。
その実用的な選択。
現代の西暦は、英国（およびその植民地）が1582年以来ほとんどのカトリックヨーロッパで採用されていたグレゴリオ暦を採用した1752年まで一貫していませんでした。
1月1日を冬至に合わせるためのうるう年などの現代暦です。
では、1752年1月1日から始めてみませんか？基本的なうるう年の規則（4桁の世紀も4で割り切れる場合を除いて、2桁の年を4で割り切れる場合はうるう年）が400年周期を確立したためです。1601年1月1日から始まる最初の完全なサイクル（少なくともローマでは）。
うるう年と日付の計算は、400年のサイクルの途中から開始しなくても十分に苦痛です。したがって、英国の日付は10日であったため、1752年より前の日付は地理的な場所で修飾する必要があることを覚えている限り、1600はかなり良いスタートです。同期していません。この時までにローマ時代の日付で。