Loading article…
タイムゾーンとは、法律、商業、社会生活において統一された標準時を採用する地域のことです。タイムゾーンは、経度を厳密に基準とするのではなく、国やその行政区分間の境界線に沿って設定される傾向があります。これは、頻繁に連絡を取り合う地域間で同じ時間を維持する方が都合が良いからです。
各タイムゾーンは、協定世界時（UTC）からの標準的なオフセットによって定義されます。オフセットはUTC-12:00からUTC+14:00までで、通常は整数時間ですが、インドやネパールなど一部の地域ではさらに30分または45分オフセットされます。タイムゾーン内の一部の地域では、年間の一部期間、異なるオフセットが使用される場合があり、通常は春と夏の間は1時間進めます。これは夏時間（DST）として知られています。
下の表では、夏時間を実施している地域を、夏時間が実施されていないときのUTCオフセットで示しています。夏時間が実施されている期間（おおよそ春と夏の間）には、UTCオフセットが1時間増加します（ロード・ハウ島を除く。ロード・ハウ島では30分増加します）。たとえば、夏時間期間中、カリフォルニア州はUTC-07:00、英国はUTC+01:00となります。
地球が球形であるため、空における太陽の見かけ上の位置、ひいては太陽時が場所によって変化します。この変化は経度1度につき4分に相当します。例えば、ロンドンで太陽正午のとき、西に約2.5度離れたブリストルでは太陽正午より約10分前になります。 [ 4 ]地方太陽時は日時計の発明以来、市民の時刻計測と関連付けられてきました。例えば、紀元前1500年頃、古代エジプトの日時計は労働者の労働時間を計測するために使用されました。[ 5 ]紀元前2世紀、ヒッパルコスは2つの場所で同時に月食が観測されたときの地方太陽時を比較することで経度距離を測定する方法を開発しました。ヒッパルコスの著作は失われていますが、紀元7年頃のストラボンの『地理誌』の引用から知られています。
1675年に設立されたグリニッジ王立天文台は、航海士が海上で経度を決定する際の補助として、グリニッジ標準時（GMT）、すなわちその場所における平均太陽時を確立し、イングランド各地で異なる時刻が用いられていた中で、標準的な基準時刻を提供した。
19世紀には、交通機関や通信技術の発達に伴い、各地点で独自の太陽時を観測することがますます困難になった。1840年11月、イギリスのグレート・ウェスタン鉄道は携帯用クロノメーターで計測したGMTの使用を開始した。[ 6 ]この方法はすぐに他のイギリスの鉄道会社にも採用され、鉄道時間として知られるようになった。
1852年8月23日頃、王立天文台から電信で初めて時刻信号が送信されました。1855年までに、イギリスの公共時計の98%がGMTを使用するようになりましたが、GMTがイギリスの法定時刻となったのは1880年8月2日でした。この時期のイギリスの時計の中には、現地時間とGMTの2本の分針を持つものがあります。[ 7 ]
1868年11月2日、イギリス領ニュージーランド植民地は、植民地全体で遵守される標準時を正式に採用した。[ 8 ]これはグリニッジの東経172度30分、つまりグリニッジ標準時より11時間30分進んだ経度に基づいていた。この標準時はニュージーランド平均時として知られていた。[ 9 ]
19世紀の北米の鉄道における時刻管理は複雑だった。各鉄道会社は独自の標準時を使用しており、通常は本社または最も重要な終着駅の現地時間に基づいていた。また、鉄道会社の列車時刻表は、その鉄道会社独自の時刻を使用して発行されていた。複数の鉄道会社が乗り入れる分岐点には、各鉄道会社ごとに時計があり、それぞれ異なる時刻を示していた。[ 10 ] このため、同じ線路を使用する異なる会社の列車がすれ違う際に、多くの事故が発生した。[ 11 ]
1863 年頃、チャールズ F. ダウドは北米の鉄道向けに時間ごとの標準時間帯のシステムを提案したが、当時この件について何も発表せず、1869 年まで鉄道関係者に相談もしなかった。1870 年、彼は南北境界を持つ 4 つの理想的な時間帯を提案し、最初の時間帯はワシントン DCを中心としていた。1872 年までに、最初の時間帯はグリニッジ子午線の西 75 度の子午線を中心とし、アパラチア山脈の一部などの自然の境界を持つようになった。ダウドのシステムは北米の鉄道に受け入れられることはなかった。 米国気象局の主任気象学者であるクリーブランド アビーは、気象観測所間の一貫性を保つために米国を 4 つの標準時間帯に分割した。1879 年、彼は「標準時間に関する報告」というタイトルの論文を発表した。[ 12 ] 1883 年、彼は北米の鉄道会社に彼の時間帯システムを採用するよう説得した。 1884年、すでにイングランド、スコットランド、ウェールズで独自の標準時システムを採用していたイギリスは、世界標準時に関する国際的な合意を集めるのに協力した。やがて、アメリカ政府は、アッベの1879年の論文の影響もあって、タイムゾーンシステムを採用した。[ 13 ]これは、トラベラーズ・オフィシャル・レイルウェイ・ガイドの 編集者であるウィリアム・F・アレンが提案したバージョンだった。[ 14 ]そのタイムゾーンの境界は、多くの場合、主要都市の鉄道駅を通っていた。たとえば、東部タイムゾーンと中部タイムゾーンの境界は、デトロイト、バッファロー、ピッツバーグ、アトランタ、チャールストンを通っていた。このシステムは、1883年11月18日日曜日、別名「2つの正午の日」[ 15 ]に開始され、各タイムゾーンで標準時の正午に達すると、各鉄道駅の時計がリセットされた。
北米のゾーンは、インターコロニアル、イースタン、セントラル、マウンテン、パシフィックと名付けられました。1年以内に、人口1万人を超えるすべての都市の85%（約200都市）が標準時を使用するようになりました。[ 16 ]注目すべき例外はデトロイト（東部時間と中部時間のほぼ中間に位置する）で、1900年まで現地時間を使用し、その後、中央標準時、現地平均時間、東部標準時（EST）を試した後、1915年5月の条例でESTが採用され、1916年8月に住民投票で承認されました。標準時ゾーンが1918年3月19日の標準時法で米国議会によって正式に採用されたとき、時間の混乱は終わりを迎えました。
イタリアの数学者キリコ・フィロパンティは、1858年に出版された著書『ミランダ！』の中で、世界規模のタイムゾーンシステムの概念を提唱した。彼は「経度日」と呼んだ24の1時間ごとのタイムゾーンを提案し、最初のタイムゾーンはローマの子午線を中心としていた。彼はまた、天文学や電信で使用される普遍的な時間も提案した。しかし、彼の著書は彼の死後ずっと後になるまで注目されなかった。[ 17 ] [ 18 ]
スコットランド生まれのカナダ人、サー・サンドフォード・フレミングは、1876年に世界標準時システムを提案した（サンドフォード・フレミング§ 世界標準時の発明者を参照）。この提案では、世界を24のタイムゾーン（Jを除く）に分け、各タイムゾーンは経度15度をカバーする。各ゾーン内のすべての時計は他のゾーンと同じ時刻に設定されるが、隣接するゾーンの時計とは1時間異なる。[ 19 ]彼は国際子午線会議を含むいくつかの国際会議でこのシステムを提唱し、そこで検討された。このシステムは直接採用されていないが、フレミングのシステムと同様に、世界を24のタイムゾーンに分け、それぞれに文字を割り当てた地図もある。[ 20 ]
1900年頃までに、地球上のほぼすべての居住地で標準時が採用されましたが、そのうちのごく一部だけがグリニッジ標準時（GMT）からの1時間ごとのオフセットを使用していました。多くの国では、GMTを参照することなく、地元の天文台の時刻を国全体に適用していました。すべてのタイムゾーンがGMTまたは協定世界時（UTC）からの何らかの標準オフセットに基づくようになるまでには、何十年もかかりました。1929年までに、ほとんどの国が1時間ごとのタイムゾーンを採用しましたが、イラン、インド、ミャンマー、オーストラリアの一部など、30分オフセットのタイムゾーンを持つ国もありました。ネパールは標準オフセットを採用した最後の国で、1986年にわずかにUTC+05:45に移行しました。[ 21 ]
現在、すべての国が世俗的な目的で標準時を使用していますが、その概念を当初の意図どおりに適用している国は限られています。いくつかの国や地域では、標準時から30分または15分のずれを設けています。中国やインドのように、領土が理想的な経度15度（1時間あたり）をはるかに超えているにもかかわらず、単一のタイムゾーンを使用している国もあります。一方、スペインやアルゼンチンのように、標準時に基づく時差を使用している国もありますが、必ずしも地理的な位置に基づいて決定される時差とは限りません。こうした状況は、地域によっては住民の生活に影響を与え、極端な場合には、中国西部のように、より大きな政治問題に発展することもあります。[ 22 ] 11のタイムゾーンがあるロシアでは、2つのタイムゾーンが2010年に廃止され[ 23 ] [ 24 ]（翌年の3月27日に夏時間が通年で実施される1年前）、2014年に復活した（この年、ロシアは夏時間から標準時間または冬時間に恒久的に移行した）。[ 25 ]
ISO 8601は、国際標準化機構（ISO）が定めた規格であり、タイムゾーンの表現方法を含む、日付と時刻をテキスト形式で表現する方法を定義している。
時刻がUTCの場合、区切りスペースなしで時刻の直後に「Z」が追加されます。「Z」はUTCオフセットがゼロであることを示すゾーン指定子です。 したがって、「09:30 UTC」は「09:30Z」または「0930Z」と表記されます。同様に、「14:45:15 UTC」は「14:45:15Z」または「144515Z」と表記されます。[ 26 ] UTC時刻は「Zulu」時刻とも呼ばれます。「Zulu」は文字「Z」を表す音声アルファベットのコードワードです。 [ 26 ]
UTCからのオフセットは、±hh:mm、±hhmm、または±hh（UTCより何時間進んでいるか遅れているか）の形式で表記されます。たとえば、記述されている時刻がUTCより1時間進んでいる場合（冬のドイツの時刻など）、タイムゾーン指定子は「+01:00」、「+0100」、または単に「+01」となります。このタイムゾーンの数値表現は、アルファベットのタイムゾーン略語（または上記の「Z」）が付加されるのと同じ方法で、現地時刻に付加されます。UTCからのオフセットは夏時間によって変化します。たとえば、北米中央時間帯にあるシカゴの時刻オフセットは、冬（中央標準時）は「-06:00 」、夏（中央夏時間）は「 -05:00 」となります。 [ 27 ]
タイムゾーンは、多くの場合「EST」、「WST」、「CST」などのアルファベットの略語で表されますが、これらは国際時刻および日付標準ISO 8601の一部ではありません。このような表記は曖昧な場合があります。たとえば、「CST」は、（北米）中央標準時（UTC−06:00）、キューバ標準時（UTC−05:00）、または中国標準時（UTC+08:00）を意味する可能性があり、また、ACST（オーストラリア中央標準時、UTC+09:30）の広く使用されているバリエーションでもあります。[ 28 ]
タイムゾーン間の変換は次の関係に従います
ここで、等式の両辺はUTCに等しい。
変換式は次のように変形できます。
例えば、ニューヨーク証券取引所は午前9時30分（ EST、UTCオフセット=-05:00）に開場します。カリフォルニア（PST、UTCオフセット=-08:00）とインド（IST、UTCオフセット=+05:30）では、ニューヨーク証券取引所は午前9時30分に開場します。
夏時間への移行時や夏時間からの移行時が近づくと、その地域のUTCオフセットがUTC時刻の関数となるため、これらの計算はより複雑になります。
時差によって日付も異なる場合があります。例えば、エジプト（UTC+02:00）で月曜日の22:00の場合、パキスタン（UTC+05:00）では火曜日の01:00になります。
「地域別時刻」表は、異なる地域間の時間的な関係の概要を示しています。
1920年代以降、外洋を航行する船舶向けに航海標準時システムが運用されている。陸上のタイムゾーンシステムの理想的な形態として、航海タイムゾーンは、 GMTから整数時間だけずれた15°のゴアで構成されている。航海日付変更線は180度子午線に沿っており、1つの15°ゴアを2つの7.5°ゴアに分割し、GMTから±12時間異なる。[ 29 ] [ 30 ] [ 31 ]
しかし実際には、各船は各地点でどの時刻を観測するかを自由に選択できる。船は特定の経度を越えた時ではなく、都合の良い時（通常は夜間）に時計を調整することを決める場合がある。[ 32 ]一部の船は、航海中ずっと出発港の時刻のままである。[ 33 ]
航海時間帯などの理想的な時間帯は、その時間帯の中央にある特定の経線の平均太陽時を基準とし、その経線から東西7.5度の範囲を境界として設定されます。しかし実際には、多くの時間帯の境界ははるかに西側に設定されており、理想的な時間帯の範囲外に位置する国も少なくありません。
例えば、本初子午線（0°）はスペインとフランスを通過していますが、両国は0度（グリニッジ標準時）ではなく、東経15度（中央ヨーロッパ時間）の平均太陽時を使用しています。フランスは以前はGMTを使用していましたが、第二次世界大戦中のドイツ占領中にCET（中央ヨーロッパ時間）に切り替えられ、戦後も元に戻しませんでした。[ 34 ]同様に、第二次世界大戦前、オランダはグリニッジ標準時より20分進んだ「アムステルダム時間」を採用していました。戦争中はドイツ時間に従うことを余儀なくされ、その後もそれを維持しました。1970年代半ば、オランダは他のヨーロッパ諸国と同様に、夏時間（サマータイム）の実施を開始しました。
タイムゾーンの境界線を理想的な子午線よりはるか西に引く理由の 1 つは、午後の日差しをより効率的に利用できるようにするためです。[ 35 ]これらの場所の中には、夏時間を使用しているところもあり、現地の太陽時間との差がさらに大きくなります。その結果、夏には、スペインの都市ビーゴの太陽正午は時計の時刻で 14:41 になります。このスペイン本土最西端の地域では、赤道から北に 42 度の位置にあるにもかかわらず、冬でも 18:00 より前に日没を迎えることはありません。 [ 36 ]夏至の頃、ビーゴの日没時刻は 22:00 以降で、同じタイムゾーンにあり、さらに北に 17 度位置するストックホルムと似ています。ただし、ストックホルムでは日の出がはるかに早いです。[ 37 ]
米国では、その理由は歴史的、ビジネス的なものでした。インディアナ州やミシガン州などの中西部の州では、インディアナポリスやデトロイトに住む人々は、コミュニケーションや取引を簡素化するためにニューヨーク市と同じ時間帯にいたいと考えていました。[ 38 ]
より極端な例として、西経165°24′に位置するアラスカ州ノームがある。これは、理想化されたサモア時間帯の中心（西経165° ）のすぐ西に位置する。それにもかかわらず、ノームは夏時間を採用したアラスカ時間（西経135°）を使用しているため、冬は太陽より2時間強、夏は3時間以上進んでいる。[ 39 ]アラスカ州コッツェブーも、同じ経線に近いが北極圏の北に位置し、 8月上旬には同じ日に2回の日没がある。1回目は日の開始時の真夜中過ぎ、2回目は日の終わりの真夜中直前である。[ 40 ]その結果、コッツェブーでは5月上旬には日没のない日が1日ある。[ 41 ]
中国は西は東経73度まで広がっているが、その全域でUTC+08:00（東経120度）を使用しているため、新疆ウイグル自治区などの中国西部では太陽の「正午」が15:00まで遅くなることがある。[ 42 ]アフガニスタンと中国の国境は、地球上で最大の地上時間帯の差を示しており、アフガニスタンのUTC+4:30と中国のUTC+08:00の間には3.5時間の差がある。
多くの国、そして時には国の特定の地域だけでも、夏時間（サマータイムとも呼ばれる）を年間の一部期間採用しています。これは通常、春の初めに時計を1時間進め、秋に元に戻す（「春に時計を進める」「秋に時計を戻す」）というものです。現代の夏時間は1907年に初めて提案され、石炭の節約を目的とした戦時措置として1916年には広く採用されました。論争はあったものの、それ以来多くの国が断続的に夏時間を採用しており、詳細は地域によって異なり、時折変更されます。赤道付近の国では、日照時間の季節差が最小限であるため、通常は夏時間を実施しません。
多くのコンピュータのオペレーティングシステムには、考えられるほぼすべての現地時間に対応するための必要な機能が備わっています。オペレーティングシステムは内部的に、通常、UTCを基本時刻基準として使用し、夏時間を含む現地時間とUTC間の変換を行います。
主に単一のタイムゾーンまたは限られたタイムゾーンのユーザー向けにウェブページを表示するウェブサーバーは、通常、時刻をローカルタイムで表示し、括弧内にUTC時刻を表示する場合があります。より国際的なウェブサイトでは、時刻をUTCのみで表示したり、任意のタイムゾーンを使用したりする場合があります。たとえば、CNNの国際英語版にはGMTと香港時間が含まれていますが[ 43 ]、米国版では東部時間が表示されます[ 44 ]。米国東部時間と太平洋時間は、世界中の読者を抱える多くの米国拠点の英語ウェブサイトでかなり一般的に使用されています。その形式は通常、W3Cノート「datetime」に基づいています。
電子メールシステムやその他のメッセージングシステム（IRCチャットなど）[ 45 ]は、UTCを使用してメッセージにタイムスタンプを付けるか、送信者のタイムゾーンをメッセージの一部として含めることで、受信プログラムがメッセージの送信日時を受信者のローカルタイムで表示できるようにします。
タイムスタンプを含むデータベースレコードは、通常UTCを使用します。特に、データベースが複数のタイムゾーンにまたがるシステムの一部である場合はなおさらです。タイムスタンプにローカルタイムを使用することは、夏時間を実施しているタイムゾーンでは推奨されません。なぜなら、年に一度、1時間の間、ローカルタイムが曖昧になる期間が発生するからです。
現代のカレンダーシステムは通常、タイムスタンプをUTCに紐付け、異なるタイムゾーンにあるコンピュータでは異なる時刻で表示します。これは電話会議やインターネット会議では有効ですが、旅行中はうまく機能しません。なぜなら、カレンダーのイベントは、イベント作成時にコンピュータやスマートフォンが使用していたタイムゾーンで発生すると想定されるためです。イベントが間違った時刻に表示される可能性があります。たとえば、ロサンゼルス在住者がニューヨークを訪れ、旅行前に午前9時の帰りのフライトをカレンダーに入力した場合（コンピュータはこれをロサンゼルス時間と想定します）、コンピュータの新しいニューヨークのタイムゾーンでは、カレンダーのエントリは正午になります。カレンダーソフトウェアは、夏時間（DST）にも対応する必要があり、通常は、夏時間への移行前に作成されたカレンダーエントリが、移行後も同じように表示されるようにしています。政治的な理由で夏時間の開始日と終了日が変更された場合、UTC時刻がずれても、カレンダーエントリは現地時間では同じままであるべきです。
LinuxやmacOSなどのUnix ライクなシステムでは、システム時刻はUnix 時刻形式で保持され、うるう秒を除いて、1970 年 1 月 1 日木曜日の協定世界時(UTC) 00:00:00 からの経過秒数を表します。[ 46 ] Unix 時刻は通常、ユーザーに表示されるときにローカル時刻に変換され、ローカル時刻でユーザーが指定した時刻は Unix 時刻に変換されます。この変換では、タイム ゾーンと夏時間ルールが考慮されます。デフォルトでは、システム構成時にタイム ゾーンと夏時間ルールが設定されますが、個々のプロセスはTZ環境変数を使用してタイム ゾーンと夏時間ルールを指定できます。[ 47 ]これにより、複数のタイム ゾーンのユーザー、または同じタイム ゾーンでも夏時間ルールが異なるユーザーが同じコンピュータを使用し、それぞれのローカル時刻が各ユーザーに正しく表示されます。タイム ゾーンと夏時間ルールに関する情報は、通常、IANA タイム ゾーン データベースから取得されます。GNU Cライブラリ、 BSD CライブラリをベースにしたCライブラリ、またはSystem V Release 4 Cライブラリを使用するシステムなど、多くのシステムがIANAタイムゾーンデータベースを利用できます。
Windows 95およびWindows NTより前のWindowsベースのコンピュータ システムではローカル タイムが使用されていましたが、Windows 95 以降および Windows NT ではシステム タイムが UTC に基づいています。[ 48 ] [ 49 ]これらのシステムでは、プログラムがシステム タイムを UTC として取得でき、年、月、日、時、分、秒、ミリ秒で表されます。[ 50 ] [ 51 ] Windows 95 以降および Windows NT 3.5 以降では、システム タイムを 1601-01-01 00:00:00 UTC からの 100 ns 単位のカウントとして取得することもできます。[ 52 ] [ 53 ]システムレジストリには、UTC からのオフセットや各ゾーンの夏時間の開始日と終了日を示すルールを含むタイム ゾーン情報が含まれています。ユーザーとのやり取りでは通常ローカル タイムが使用され、アプリケーション ソフトウェアはさまざまなゾーンの時間を計算できます。ターミナルサーバーを使用すると、リモートコンピュータはタイムゾーン設定をターミナルサーバーにリダイレクトできるため、ユーザーはデスクトップ/アプリケーションセッションで自分のタイムゾーンに合った正しい時刻を確認できます。ターミナルサービスは、ターミナルサーバー上のサーバーベース時刻とクライアントのタイムゾーン情報を使用して、セッション内の時刻を計算します。
ほとんどのアプリケーション ソフトウェアは、タイム ゾーンと夏時間ルール情報に基盤となるオペレーティングシステムを使用しますが、Java プラットフォームはバージョン 1.3.1 以降、 IANA タイム ゾーン データベースに基づいて、タイム ゾーンと夏時間ルール情報の独自のデータベースを維持しています。このデータベースは、タイム ゾーンまたは夏時間ルールが変更されるたびに更新されます。Oracleはこの目的のために更新ツールを提供しています。[ 54 ]
Java Platform にバンドルされている情報の代わりに、プログラマーは Joda-Time ライブラリを使用することもできます。[ 55 ]このライブラリには、IANA タイムゾーンデータベースに基づいた独自のデータが含まれています。[ 56 ]
Java 8以降では、時刻変換に役立つ新しい日付と時刻のAPIが提供されています。[ 57 ]
従来、 JavaScriptにはタイムゾーンのサポートがほとんどありませんでした。基本的に、プログラマーはタイムオブジェクトをインスタンス化し、そこからGMT時刻を取得して、両者の差分を取ることでUTCオフセットを抽出する必要がありました。これでは、北半球と南半球で異なる夏時間など、より複雑な夏時間変動に対応することはできません。
JavaScript の国際化 API の標準である ECMA-402 は、タイム ゾーンをフォーマットする方法を提供します。[ 58 ]ただし、サイズの制約により、一部の実装やディストリビューションには含まれていません。[ 59 ]
Perlの DateTime オブジェクトは、 IANA タイムゾーン データベースのすべてのエントリをサポートし、タイムゾーンの取得、設定、および変換機能を備えています。[ 60 ]
DateTime オブジェクトと関連関数は、PHP 5.2 以降、PHPコアに組み込まれています。これには、デフォルトのスクリプト タイム ゾーンを取得および設定する機能が含まれており、DateTime は内部的に自身のタイム ゾーンを認識しています。PHP.net には、これに関する詳細なドキュメントがあります。 [ 61 ]そこに記載されているように、最新のタイム ゾーン データベースはPECL timezonedb を介して実装できます。
Pythonに付属する標準モジュール datetime は、タイムゾーン情報クラス tzinfo を格納し、それに基づいて動作します。サードパーティの pytz モジュールは、IANA タイムゾーンデータベース全体へのアクセスを提供します。[ 62 ]秒単位の負のタイムゾーンオフセットは、time.timezone および time.altzone 属性に格納されます。Python 3.9 以降、zoneinfo モジュールはサードパーティのモジュールを必要とせずにタイムゾーン管理を導入します。[ 63 ]
Smalltalkの各方言には、日付、時刻、タイムスタンプ用の組み込みクラスがそれぞれ用意されていますが、ANSI Smalltalk標準で規定されているDateAndTimeクラスとDurationクラスを実装しているのはごく一部です。VisualWorksは、年間2回までのオフセット遷移をサポートするTimeZoneクラスを提供しており、これはすべての年に適用されるものと想定されています（Windowsのタイムゾーンと同じ動作）。Squeakは、オフセット遷移を一切サポートしないTimezoneクラスを提供しています。Dolphin Smalltalkは、タイムゾーンを全くサポートしていません。
Smalltalkアプリケーションでtzデータベース（zoneinfo）を完全にサポートするには（任意の数の年間繰り返しオフセット遷移のサポート、および異なる年における異なる年内オフセット遷移ルールのサポートを含む）、サードパーティ製のオープンソースでANSI-Smalltalk準拠のChronos Date/Timeライブラリが、VisualWorks、Squeak、Gemstone、またはDolphinのいずれかのSmalltalk方言で使用できます。[ 64 ]
軌道上の宇宙船は、24 時間のうちに何度も日の出や日の入りを経験したり、全く経験しなかったりすることがあります。そのため、太陽を基準に時刻を較正しながら 24 時間の睡眠/覚醒サイクルを維持することは不可能です。宇宙探査では、打ち上げ場所やミッションコントロールの地球時間を使用し、乗組員と管制官の睡眠サイクルを同期させるのが一般的な方法です。国際宇宙ステーションは通常、協定世界時(UTC) を使用します。[ 65 ]
火星では、太陽日が約24時間40分（ソルと呼ばれる）であるため、時間の計測はより複雑になる可能性がある。一部の火星探査ミッションの地球管制官は、特に太陽光発電による探査車の活動が行われる際に、睡眠/覚醒サイクルを火星の1日に同期させている。[ 66 ]
ウィキメディア・コモンズにあるタイムゾーン関連のメディア