web-dev-qa-db-ja.com

1641年にファイルはどのように「作成」されたのでしょうか。

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

Screenshot of a file properties dialog in Microsoft Windows

そして、1641年にファイルが作成されたと言うのはどうしてだろうか。私の知る限りでは、PC上の時間は1970年1月1日からの秒数で定義されます。そのインデックスが故障した場合、あなたは1969年12月31日を得ることができます。一見ランダムな日付、それはアメリカ合衆国の設立さえ前に。

それでは、1641年にファイルの日付を記入するにはどうすればよいでしょうか。

シモンズ:日付はフランス語です。フェブリエは2月です。

74
Fredy31

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

Windowsはファイル修正タイムスタンプ nixシステムのように を保存しません。 Windows Dev Center (私の強調点)によると、

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

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

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

これは2038年問題とどのように関連しますか。

64ビットのデータ型を使用することは、Windowsが(一般的に)伝統的なUnixシステムが持っている 2038年問題 の影響を受けないことを意味します。 Windowsが持っている64ビット整数。 (これはUnixが数秒で動作し、Windowsがマイクロ/ナノ秒で動作しているにもかかわらずです。)

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

新しいUnixオペレーティングシステム すでに拡張済み データ型を64ビットにしたため、この問題は回避されました。 (事実、Unixのタイムスタンプは数秒で動作するので、新しいラップアラウンド日は今から2920億年になります。)

設定できる最大日数は?

好奇心が強い人のために - これを計算する方法は次のとおりです。

  • 64ビット整数内の可能な値の数 は、2です。63 - 1 = 9223372036854775807
  • 各ティックは100ナノ秒を表し、0.1マイクロ秒または0.0000001秒です。
  • 最大時間範囲は9223372036854775807⨉0.0000001秒なので、数千億秒になります。
  • 1時間は3600秒、1日は86400秒、1年は365日です。したがって、1年には86400×365秒= 31536000秒があります。もちろんこれは平均的なものにすぎず、うるう年、うるう秒、または将来のポスト終末論的政権が残りの地球環境に影響を与える可能性のあるカレンダーの変更を無視したものです。
  • 9223372036854775807⨉0.0000001 s/31536000 s≈29247才
  • @corsiKa は、うるう年を差し引く方法を説明したものです。29247/365/4≈20
  • だからあなたの最大年は1601 + 29247 - 20 = 30828です。

何人かの人々は 実際にこれを設定しようとしました を持ち、同じ年を思い付きました。

106
slhck

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

Unix時間は通常1970年以来の秒数を使用します。一方、Windowsはその開始年として1601年を使用します。そのため、問題が2回の変換で間違っていると仮定した場合(そしてそれは大きな仮定です!)、表現されるはずだった日付は実際には 2011年のいつか(1970 + 41)、1640(1601 + 41)に誤って変換されました。編集:実際には、私は最初の年にWindowsに間違いを犯した。実際の作成時間は2010年であるか、もう1つのエラーが関与している可能性があります(ソフトウェアでは1つずつのエラーがかなり一般的です)。

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

16
Luaan

他の人が書いたように、 Windows Epochは1601-01-01 00:00です

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

5
SQB

これらの種類の質問ではいつものように、Raymond Chenのブログは「なぜWin32 Epochが1601年1月1日なのか」からこの答え を得ています。 2009年3月6日からのエントリー:

FILETIME構造体は、1601年1月1日からの経過時間を100ナノ秒の間隔で記録します。その日付が選ばれたのはなぜですか?

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

私は実際にこれを確認するDave Cutlerからの電子メールを持っています。

2
ErikF