1641年にどのようにしてファイルを「作成」できましたか？

数年前、私はファイルサーバーでこのファイルを見つけました。

また、1641年に作成されたとファイルに表示する方法はありますか？私の知る限り、PC上の時間は1970年1月1日からの秒数によって定義されます。そのインデックスがグリッチした場合、1969年12月31日を得ることができます（インデックスはおそらく-1を示します）が、これには困惑しています一見ランダムな日付であり、アメリカ合衆国の設立よりも前の日付です。

では、1641年のファイルの日付はどのようになっているのでしょうか？

PS：日付はフランス語です。Févrierは2月です。

1600年代の日付が可能なのはなぜですか？

Windowsは、Unixシステムのようなファイル変更タイムスタンプを保存しません。Windows Dev Center（エンファシス鉱山）によると：

ファイル時間は、1601年1月1日午前12:00から協定世界時（UTC）を経過した 100ナノ秒間隔の数を表す64ビット値です。システムは、アプリケーションがファイルを作成、アクセス、および書き込みするときのファイル時間を記録します。

したがって、ここで間違った値を設定することにより、1600年代から簡単に日付を取得できます。

もちろん、もう1つの重要な質問は、この値がどのように設定されたかです。実際の日付は何ですか？ファイルシステムドライバーの計算エラーである可能性があるため、見つけることができないと思います。別の答えは、日付は実際にはWindowsタイムスタンプとして解釈されるUnixタイムスタンプであるが、実際には異なる間隔（秒対ナノ秒）で計算されるという仮説です。

これは2038年問題にどのように関係しますか？

Unixは最初に32ビット整数を使用していたため、Windowsは（一般的に）従来のUNIXシステムが抱えていた2038年問題の影響を受けません。これは、Windowsが64ビット整数持っています。（これは、Unixが数秒で動作し、Windowsがマイクロ/ナノ秒で動作しているにもかかわらずです。）

もちろん、古いバージョンのVisual Studioでコンパイルされた32ビットプログラムを使用している場合、Windows は依然として影響を受けます。

新しいUnixオペレーティングシステムでは、既にデータ型が64ビットに拡張されているため、この問題は回避されています。（実際、Unixタイムスタンプは数秒で動作するため、新しいラップアラウンドの日付は今から292億年です。）

設定できる最大の日付は何ですか？

好奇心ones盛な人のために–これを計算する方法は次のとおりです。

• 64ビット整数で可能な値の数は2 ⁶³ – 1 = 9223372036854775807です。
• 各ティックは100ナノ秒を表します。これは0.1 µsまたは0.0000001 sです。
• 最大時間範囲は9223372036854775807⨉0.0000001秒なので、数千億秒になります。
• 1時間には3600秒、1日には86400秒、1年には365日があるため、1年には86400×365秒= 31536000秒があります。これはもちろん、average年、うるう秒、または将来の黙示録的な政権が残りの地球人に命令するかもしれないカレンダーの変更を無視して、平均に過ぎません。
• 9223372036854775807⨉0.0000001秒/ 31536000秒≈29247年
• @corsiKaうるう年を減算する方法を説明します：29247/365/4≈20
• したがって、最大年は1601 + 29247 – 20 = 30828です。

一部の人々は実際にこれを設定しようとし、同じ年を思いついた。

推測についてあまり気に入らない場合は、説明をさせてください。そして、私は「誰かがナンセンスに値を設定する」という意味ではありません、それは明らかに常に可能です:)

Unix時間は通常1970年以降の秒数を使用します。一方、Windowsは開始年として1601を使用します。したがって、2回の間で問題が間違った変換であると仮定すると（そしてそれは大きな仮定です！）、表現されるはずの日付が実際には2011年（1970 + 41）のどこかにあると想像できます。1640（1601 + 41）まで。編集：実際、私はWindowsの開始年に​​間違いを犯しました。実際の作成時間は2010年であったか、または別のエラーが関係していた可能性があります（ソフトウェアでは、オフバイワンエラーはかなり一般的です：D）。

今年は問題のファイルに関連付けられた追跡日付の別の日であることを考えると、私はそれがかなりもっともらしい説明だと思う:)

他の人が書いたように、Windowsエポックは1601-01-01 00:00です。

そのエポックと表示されるファイル時間との間の秒数は1.266.705.294です。
それをUnixエポックに追加すると、土曜日の2010-02-20 23:34:54 CESTに到達します。これは最終アクセス日から約1年前であり、ある程度妥当と思われます。したがって、誤ったエポックに対して解釈されたUnixタイムスタンプである可能性があります。

これらのタイプの質問でいつものように、Raymond Chenのブログには、「Win32エポックが1601年1月1日である理由」からこれに関する回答があります。2009年3月6日からのエントリー：

FILETIMEその日が選ばれたのはなぜな構造は、1601年1月1日以降の100ナノ秒間隔の形式で時刻を記録しますか？

グレゴリオ暦は400年のサイクルで動作し、1601はWindows NTが設計された時点でアクティブだったサイクルの最初の年です。言い換えれば、数学がうまく出てくるように選ばれました。

実際に、これを確認するDave Cutlerからのメールがあります。