2009-06-08 6 views
2

ほとんどの言語には、日付機能/オブジェクトから取得した日付情報を取得するためのプログラミングを実際に行う必要のない、ある種の日付機能があります。これを実現させるためにシーンの裏側で何が起きているのか不思議です。コンピュータはどのように日付情報を把握していますか?

+0

あなたはここでどんなパズルをしているのか、もっと具体的になりますか? – Joey

+2

たくさん...あなた自身では書いていません:P – workmad3

答えて

8

すべてのコンピュータには、日付と時刻を記録するシステムクロックがあります。最下位レベルで、そこから検索された日時情報。上記では、オペレーティングシステムからタイムゾーン情報などを追加し、Dateオブジェクトなどを取得しています。

言語/環境によって異なります。日付オブジェクトは、日付計算自体を実行することも、それを達成するために他の関数を使用することもできます。これにより、うるう年が正しく処理され、無効な日付を作成することができなくなります。

しかし、おそらくあなたの質問が間違っています。

3

通常、オペレーティングシステムによって日付と時刻の情報が提供されるため、システムコールです。オペレーティングシステムは、コンピュータのメインボードに搭載されたリアルタイムクロックを扱い、小型バッテリ(長年続く)によって駆動されます。

5

通常、コンピュータには過去の特定の日時以降に経過した時間単位の数が格納されています。たとえば、Unixシステムでは、これはUnix Epochからの秒数で、GMT 1970年1月1日の深夜です。 Windowsでは、これは1601-01-0から100ns間隔の数です(JohannesRössel)。それとも、コンピュータの電源が入ってから数秒もの時間がかかることがあります。

したがって、その時間/日付以降に経過したユニットの数から、OSは、経過した年月日を計算することができます。もちろん、うるう年やうるう秒のようなあらゆる種類の面白いものが考慮されなければなりません。

NTP (Network Time Protocol)などのシステムを使用して、ネットワーク上のNTPサーバー経由でコンピュータの内部カウントをアトミッククロックに同期させることができます。これを行うために、NTPはラウンドトリップ時間を考慮に入れ、NTPサーバへのリンクのエラーの種類を学習します。

+2

すべての日付/時刻システムがエポックベースであるとは限りません。また、すべてのエポックベースのものは第2ベースのものではありません。たとえば、Windowsでは1601-01-01以降に100 nsの間隔が使用されます。 – Joey

+0

@Johannes WindowsがUNIXとは異なる時代を遂げていることは分かりませんでした。彼らはどちらも1970年に基づいていると思っていました。 – RichardOD

+0

リチャード:Windows NTは400年の閏年サイクルの始まりをコンセプション(1993)で選んだ1601年に始まった。また、彼らは最初から64ビットの値を使用していたので、1世紀ほどの長さのタイムパンフだけを心配する必要はなかった。それでも、Windowsは異なる時間形式で散らばっていますが、少なくとも2つあります。そのうちの1つはSYSTEMTIME(いくつかのフィールドを持つ単純な構造体)です。もう1つは人間が読める文字列です(ただし名前は現在はありません)。 – Joey

1

お使いのコンピュータにはシステムクロックがあり、BIOSにはお使いのOSからアップデートできるタイマー機能があります。言語はそこから情報を取得するだけで、一部はそれを更新することもできます。

3

まあ...ほとんどのコンピュータには人間の尺度で時間を数えた "real-time clock"が含まれています。伝統的に、マザーボードには小さな電池があり、チップに時間を覚えています。残りのコンピュータの電源が切られている場合でも、それを数え続けます。

現在、多くのコンピュータでは、network time protocolのようなサービスを使用して、現在の時刻を設定するために、高精度クロックを集中的に照会します。このようにして、バッテリが取り外された場合(または失敗した場合でも)、コンピュータはそれが何時であるかを依然として知り、更新することができる(リアルタイムチップの時間管理におけるエラーを修正するために)その情報必要に応じて頻繁に

1

Calendrical Calculationsでこれらの書籍を購入してください。彼らは日付ライブラリがどのようにボンネットの下で動作するかについてあなたに記入します。

1

日付/時刻は、特定の日付以降の時刻で保存されることがよくあります。たとえば、0001年1月1日以降のティック(100ナノ秒の間隔)。これは、UTCを参照して自動的に保存されます。 OS、データベース、フレームワーク、アプリケーションなどの基礎となるメソッドは、これらをより使いやすい表現に変換できます。今日では、システムは日付、日、月、年などの構成部分をデータ構造の一部として格納しますが、Y2Kの混乱の教訓は、これがおそらく最善の方法ではないことを学びました。

3

リアルタイムクロックとは別に、日付計算は主にソフトウェアライブラリ関数です。

日付はむしろ不規則で、裏には近似値、訂正値、ルックアップテーブルが混在しています。

日付の表記も同様に異なる場合がありますが、通常は(任意の)開始日が使用されます。天文学者によっても使用される一般的なシステムは、Julian day numbersです(Julian calendarと混同しないでください)。日付は、開始時の秒数または開始日数(後者は通常は浮動小数点数)として格納できます。ここにはsome more algorithmsがあります。

+0

The Julianカレンダーは必ずしも閏年が正しいとは限りません。現代のシステムでは、グレゴリオ暦を使用していますが、これはジュリアンとほとんど同じですが、うるう年が正しいものになります。 –

+0

現代のシステムだけでなく、数世紀前にユリウス暦が置き換えられました。リンクされたページにすべてあります。 –

2

驚くほど複雑なコードの驚くべき量は、等たとえば

日付解析、計算、作成に必要とされる、Javaで、日付が具体的かつ典型的には、計算された修飾、DateCalendar介し等格納され、 、Gregorian Calendar implementation of Calendar。 (あなたはdownload the SDK/JDKで、あなた自身のためにソースを見てください)

要するに、私がソースの素早い見解から取ったものは次のとおりです。日付の取り扱いは自明ではありません。可能であれば良いライブラリを見つけてください。そうでなければ、確かにreinventing the square wheelになります。

1

ほとんどの返信は、現在の日付の取得方法と関係しています。すなわちシステムクロックなどである。

保存方法と使用方法を知りたい場合は、さまざまな実装があり、システムによって異なります。

T-SQLでは64ビット符号付き整数を使用するのが一般的だと思います.1970年1月1日は0なので、負数は1970より前であり、各増分から100番目の秒が加算されますチェックする必要があるのは100番だと思います)。

なぜ01/01/1970なのかは、グレゴリオ暦が400年周期にあるためです。 01/01/1970は、現在の日付までのサイクルの終了を示します。

これは「毎年正確に4で割り切れる年は閏年ですが、100で割り切れる年を除いて、正確に400で割り切れる年の年はまだ閏年です。たとえば、年1900年はうるう年ではなく、2000年はうるう年です」それは非常に複雑になります私は400年のサイクルが繰り返されている週の曜日と一致すると信じていますが、元気なチェックはしません。基本的には非常に複雑です。

内部的には、うるう年などのこれらのすべてのバリエーションを対象とするdatetimeライブラリを記述することは非常に困難です。実際には年が0ではありません..... UTC、GMT UT1回はもちろんです。

1

私は、クライアントの問題をデバッグして、SQLがデータセットをどのように格納するかを調べる機会を得ました...かなり興味深いものです。

SQLは2つの4バイト整数を使用します... 最初の4バイトは1753年1月1日からの日数です。私は最大年が9999であると考えています。利用可能な整数の数は4バイトですが、そこに行きます。 2番目の4バイトは深夜からのミリ秒単位の時間です。

関連する問題