何日も前に、私は近年 、テストに従事していた間に形成された観察のいくつかを記録することにしました。 テストを最大限に活用する分野を考えると、私たちプログラマーがプログラミングの「時間」の概念を何気なく扱う傾向があることについて、多くの具体的な考えを蓄積していることに気付きました。

それから、 「時間に関するプログラマーの誤解」という投稿を書きました。そこでは、カレンダーとシステム時間の両方に関する34の誤った表現と誤解を示しました。 私はそれらの大部分に自分で出会い、プログラムのデバッグ（作業とテストの両方）を行いました。


これらの誤解の多くは私自身のものでした。 特に、「タイムスタンプは常に時代の始まりから数秒単位」であり、「システムクロックの1分間は常に物理時間の1分間に近い」。 私の生涯、私はこれらの2つのケースで私のエラーを痛々しいほど思い出します！ しかし、もちろん、間違いなく、このような問題に遭遇した（または誤って作成した）のは私だけではありません。 多くの人々が同様の経験に応え、共有しました。

更新：この投稿の議論に参加したすべての人に心から感謝します。 私はすべてのコメントを読み、たとえば年間ゼロ時間や国際原子時間など、さまざまな面白いことについて学びました。

BoingBoing 、 Hacker News 、 Reddit 、 MetaFilter 、Twitterについての議論に貢献し、プログラミングの「時間」との彼の異常な経験を共有してくれたすべての人に感謝したいと思います。 この約1000の回答には、「誤解」のリストを継続する多くの提案がありました。

まず、 テクノマンシーや他の多くの人が指摘しているように、「時間は常に前進する」という誤った仮定がありませんでした。 リストのすべての提案を読んで楽しかったです。 読み終えたとき、私は概して、それらが単なる別のブログ投稿であることに気付きました。 したがって、私はあなたの提案をすべて1つの投稿に集め、それを以下に示します。

これらの仮定はすべて間違っています。

以下の時間ベースの仮定はすべて、 最初の投稿の議論の参加者によって提案されました。 各参加者は記事の最後にリストされています。

1. 2つのタイムゾーンの差は一定です。
2.さて、 歴史的な好奇心はさておき 、2つのタイムゾーンの差は今後も変わらないでしょう。
3.時間帯間の差の変化は、多くの予備アラートの発行に伴い発生します。
4.夏時間は毎年同時に発生します。
5.夏時間は各タイムゾーンで同時に発生します。
6.夏時間に切り替えると、常に1時間のシフトがあります。
7.月の日数は28、29、30、または31です。
8.月の日は常にNからN + 1または1に連続して変化し、ギャップはありません。
9.一度に使用されるカレンダーシステムは1つだけです。
10. 各年にうるう年が4で割られます。
11. leanせた年には2月29日はありません。
12.特定の時点から経過した時間と分数を数えるのは簡単です。
13.同じ月にはどこでも同じ日数が含まれています！
14. Unix上の時間は秒単位でのみ測定されます。
15. Unix時間は、1970年1月1日からの秒数です。
16.土曜日は常に金曜日が先行します。
17.隣接するタイムゾーンの違いは1時間以内です（言い換えると、日付変更線を飛行するときに航空電子機器に何が起こるかをチェックするべきではありません）。
18. 2つの異なるタイムゾーンは、30分の整数で異なります。
19.わかりました、1時間の整数の整数。
20.わかりました。数秒ですが、夏時間を考慮しない場合は大きな違いになります。
21. 2つの日付オブジェクトを隣り合わせに作成すると、それらは同じ時刻を表します（ハイゼンベルクの素晴らしいジェネレーター）。
22.クロックに正確にHH：MM：SSが1秒に1回サンプリングされるまで待つことができます。
23.プロセスが「n」秒進んでから終了する場合、システムクロックで完了までに約「n」秒が経過しています。
24.週は月曜日に始まります。
25.日は朝から始まります。
26.祝日には整数の日数がかかります。
27.週末は土曜日と日曜日から成ります。
28.システムの外部で役立つ一般的なタイムスタンププロセスを設定できます。
29.現地時間のオフセット（協定世界時（UTC）に対する）は、就業日中は変更されません。
30. Thread.sleep（1000）は、1000ミリ秒間実行を一時停止します。
31. Thread.sleep（1000）は、1000ミリ秒以上の時間実行を一時停止します。
32.各分には60秒が含まれます。
33.タイムスタンプは常に単調に動いています。
34.グリニッジ標準時（GMT）と協定世界時（UTC）は同じタイムゾーンを表します。
35.イギリスではグリニッジ標準時（GMT）を使用しています。
36.時間は常に進みます。
37.現在の時点と1週間離れた時点との差は、常に7 * 86400秒に等しくなります。
38. 2つのタイムスタンプの違いは、それらの間の経過時間の正確な尺度です。
39. 24:12:34-間違った時間。
40.各整数は理論的には1年を意味します。
41.日付と時刻が表示されるとき、表示される時刻はメモリに保存されている時刻と同じ秒部分を持ちます。
42.または同じ年。
43.しかし、少なくとも、表示された年と保存された年の差は2を超えません。
44.データが正しい形式YYYY-MM-DDの場合、年には4桁が含まれます。
45. 2つの日付が最初の月から1日、2番目の日および/または年を借用して結合する場合、日付は正しいです。
46.しかし、これは両方の年がうるう年の場合にのみ機能します。
47. W3C仕様で説明されている公開されたアルゴリズムを使用して日付に期間を追加すると、すべての場合に機能します。
48.標準ライブラリは、負の年および10,000を超える年をサポートしています。
49.タイムゾーンは常に1時間異なります。
50.ミリ秒単位の精度を持つタイムスタンプを秒単位の精度を持つ時間に変換する場合、ミリ秒単位のコンポーネントを安全に無視できます。
51. 0.5未満のコンポーネントはミリ秒単位で無視できます。
52. 2つの数字で表された年は、1900〜2099の範囲にある必要があります。
53.時刻、日付を解析するとき、戻ることなく番号を（文字ごとに）順番に読み取ることができます。
54.時刻、日付を印刷するとき、戻ることなく連続して（文字ごとに）数字を書き込むことができます。
55. 12ZまたはP12Y34M56DT78H90M12.345Sのようなものを解析する必要はありません。
56.タイムゾーンは24のみです。
57.タイムゾーンは常に、世界標準時（UTC）に対して整数の時間数だけ異なります。
58.夏時間はどこでも同じ日に開始/終了します。
59.夏時間は常に1時間進んだ時間を表します。
60.クライアントの時間を読み取り、UTCと比較することは、クライアントのタイムゾーンを判断する良い方法です。
61.ソフトウェアで実装されたスタックは、タイムゾーン/夏時間に自動的に調整しようとします/しません。
62.私のプログラムは内部/ローカルでのみ使用されるため、タイムゾーンについて心配する必要はありません。
63.私のソフトウェアスタックは、私の介入を必要とせずにこれを処理します。
64.自分でタイムゾーンのリストを簡単に保存できます。
65.特定のクロックでのすべての時間測定は、同じ参照フレームで行われます。
66.日付ベースの関数が現在機能しているということは、どの日付でも機能することを意味します。
67.年には365日または366日が含まれます。
68.各カレンダーの日付の後ろには、パスなしでさらに順番があります。
69.指定された日付および/または時刻表示は、一意の時点を一意に識別します。
70.うるう年は4年ごとに発生します。
71.地域/地区を知っていれば、彼らのタイムゾーンを決定できます。
72.地域を知ると、そのタイムゾーンを決定できます。
73.山の頂上と谷の最下部では、同じ速度で時間が流れます。
74.すべての時間枠で、1時間は次の時間と等しくなります。
75.うるう秒がいつ追加されるかを計算できます。
76. getCurrentTime（）によって返されるデータ型の精度は、この関数の精度と同じです。
77. getCurrentTime（）を2回連続して呼び出すと、異なる結果が返されます。
78. getCurrentTime（）の2つの連続した呼び出しの2番目は、より大きな値を返します。
79.このソフトウェアは、ブラックホールの周りを飛行する宇宙船では動作しません。

ほんと？ ブラックホール？

まあ、 ブルーススターリングが私のソフトウェアがブラックホールの近くの一時的な歪みに対して安定しているべきだと言ったら-私はそれを一言で捉えます。