確かに、これらのステートメントの一部（すべてではないにしても）がいつでもどこでも当てはまると確信しています。
- 1日は常に24時間です。
- 1週間は常に同じ月に始まり、同じ月に終わります。
- 週（または月）は常に同じ年に開始および終了します。
- 時間には始まりも終わりもありません。
- 1か月に28日、29日、30日、または31日かかる場合があります。
- 4年ごとにうるう年があります。
- 毎月、日数はどこでも同じです。
- サーバーとクライアントは常に同じ時刻になります。
- ある時点から始まる時間と分の数を簡単に計算できます。
- 1分あたり60秒です。
実践は、ソフトウェアを開発するときにこれらのステートメントの真実に依存することは妄想であることを示していますが。さて、これらの点のすべてが誤解であるわけではありません 。ソフトウェアの歴史上無数に蓄積されてきた厄介なバグやエッジケースがなければ、いくつかの記述は真実です。
1分あたり60秒で、1日は常に24時間です。
たとえば、CentOSの古いバージョンのKVMには、奇妙なバグがありました。1分は好きなだけ続く可能性があります。実際、KVMは物理ハードウェアで実行されていないことを認識していませんでした。ホストOSが仮想マシンを一時的に停止した場合、仮想化されたクロックは停止された瞬間から実行され続けました 。たとえば、車が13:00に一時停止され、15：00にアクティブ化された場合、その車のシステムクロックは引き続き13:00を示します。その結果、一時停止するたびに、リアルタイムとの不一致が発生しました。仮想化されたクロックをハードウェアクロックと同期するように設定できるcronタスクもありました。しかし、新しい仮想マシンを作成するとき、それを忘れがちで、楽しかったです。バグは後で修正されました。
バグとは別に、うるう秒（追加）秒もあります。これは、地球の自転の段階的な減速を補うために、6月30日または12月31日の終わりにUTC（協定世界時）に追加されます。 SIと天文日との差の蓄積-晴れ-何日も。
1日の長さに関しては、プログラマーの主な敵は夏時間への移行です。これはどこかにあり、どこかにありません。以前はキャンセルまたは導入される可能性があります。これは、履歴データに関する別の大きな問題であり、夏時間です。
そして、これにタイムゾーンの変更を追加すると...
約数週間、数ヶ月、数年
しかし、月と年の長さが異なるという話は、世界のさまざまな人々のさまざまなカレンダー計算に関連付けられています。たとえば、ヘブライ暦は太陰暦で動作します。つまり、月の初めと終わりは月の満ち欠けに関連付けられています。月の満ち欠けの負荷でイスラエルの調整を追加することで、これを簡単に考慮に入れることができると思いますか？動作しないでしょう。ユダヤのうるう年では、1か月が追加され ます。さらに、-手を見てください-ヘブライ暦の単純な年とうるう年の両方に、 3つの異なる長さがあります。合計で、1年は6つの異なる長さにすることができます 。354日から383日。これが私たちのカレンダーとの違いが終わったところだと思いますか？ある場所：ユダヤ暦では、日はさまざまな期間を持ち、日没から日没まで（正式には、3つの星が空に見えるようになるとき）カウントさ れます。
グレゴリオ暦（11月7日にソ連で祝われた十月革命の問題）のすべてがそうではないのはユダヤ人だけだと思いますか？アラブ諸国：
- 週は月曜日ではなく、日曜日に始まります。
- 週末は金曜日と土曜日と見なされ、一部の国では木曜日と金曜日と見なされます。過去10年間で、一部の州は国際貿易を促進するために週末を金曜日と土曜日に移動しました。それでも、すべてのアラブ諸国が2日間の週末を持っているわけではありません。
- 宗教上の祝日は月の周期の観測に依存しているため、そのタイミングを正確に予測することはできません。
週と月が来年終了する可能性があるという事実に関しては、これも太陰暦と太陽暦のある国では一般的です。それらの国では、新年は1月1日から始まりません。グレゴリオ暦によると、1月21日から2月21日までの期間に新年が始まる中国人をすぐに思い出すことができます。そして、エチオピア暦では、新年は通常8月29日または30日であり、その年数でさえ「キリストの誕生から」のシステムよりも8年少なくなっています。
サーバーとクライアントは常に同じ時間を持ちます
そして、ここに興味深い事実があります。そのため、異なるコンピューターでの時間が一致するだけでなく、不一致のサイズも異なる場合があります。 Linuxが起動すると、現在のハードウェア時間がかかり、さらにカウントダウンして、内部プロセッサクロック（TSC）からデータを追加します。これらの時計はかなり不正確になる可能性があります。たとえば、TSC周波数を動的に変更するクロックスケーリングが原因です。また、ホストのクロック周波数を変更すると、すべてのゲストアカウントがそれに気付くことさえありません。 TSC周波数を50％スケーリングすると、時間は2倍遅くなり始めます。さらに、一部のサーバーでは、BIOSがOSに通知せずにプロセッサ周波数をスケーリングできるため、エラーも発生します。新しいプロセッサでは、TSC周波数が修正されました。ちなみに、WindowsはTSCを使用していないため、このOSにはタイミングに関する他の問題があります。）
ある時点から始まる時間と分の数を簡単に計算できます
プログラミング言語にPythonのようなものがない限り
tzinfo()
、過去の日付に時間と分を追加するだけでは、特定の日付と時刻を取得することはできません。タイムゾーン（および履歴で複数回発生した可能性のある変更）を考慮に入れてから、夏時間への移行におけるすべての変更を考慮する必要があります... Windowsでは、これは一般的に不可能です。マイクロソフトは今年の初めと終わりしか提供していないからです。驚いたことに、非常に多くのDST処理パッチを適用した後、同社はまだWindowsに相当するものを実装していません
tzinfo()
。おそらくそうではありません。
時間には始まりも終わりもない
「あなたのプログラムは、1970年より前の日付を処理する必要はありません。」 Unixシステム（LinuxおよびiOSを含む）では、時間は1970年1月1日UTC（協定世界時）の00:00:00から秒単位でカウントされます。 Unixの初期のものは、すでにマイナスの時間になります。さらに、時刻は32ビット整数式で表され、Unixシステムで可能な最も早い日付は1901年12月13日です。また、「トップ」Unix時間は、カウントダウンの開始からの秒数が2 31に達する2038年1月19日に制限され 、この数はシステムによって負と見なされます。
これはすべて、時間のかかる製品の開発者が対処しなければならない膨大な数のニュアンスやバグのほんの一部にすぎません。確かにあなたはあなたの経験から伝えるべき物語も持っています、コメントに書いてください。