タイムゾーン変換 preview

タイムゾーン変換

異なるタイムゾーン間の時刻を瞬時に変換します。基準と対象のゾーンを選ぶと変換後の時刻を表示します。

Guide

タイムゾーンは世界を同じ標準時を観測する地域に分割します。タイムゾーン間の変換は、国際チームと働く人、国をまたいで電話を予定する人、旅行を計画する人、他地域からの中継を追う人にとって日常の必需です。本ガイドでは、タイムゾーンの仕組み、主要な規則と例外、ゾーンをまたぐ時間管理の実用的戦略を取り上げます。 世界は24の主要なタイムゾーンに分かれ、それぞれがおおむね地球の自転1時間分に相当する15度の経度幅です。協定世界時（UTC、旧 GMT）が参照点となります。本初子午線の東側のゾーンは UTC より進み（UTC+1、UTC+2 など）、西側は遅れます（UTC-1、UTC-2 など）。太平洋の180度子午線におおむね沿った国際日付変更線で、暦の日付が変わります。 UTC と GMT は日常会話では同義に使われますが、技術的には異なります。GMT はタイムゾーン（英国の冬に使用）です。UTC は原子時計に基づく時刻標準で、いかなる場所にも結びつきません。UTC は夏時間を観測しません。精度が重要な場合は UTC を使いましょう。実際には、極めてまれなうるう秒調整時を除き、UTC+0 と GMT は同じ時計の時刻を指します。 現実のタイムゾーンはきれいな経度線には従いません。政治的境界、経済的結びつき、実際的な考慮により、ゾーンは国や州の境界の周りでジグザグに曲がります。5つの地理的タイムゾーンにまたがる中国は、全国で単一のタイムゾーン（UTC+8）を使います。これは中国西部で日の出が午前10:00にもなり得ることを意味します。インドは30分オフセットの UTC+5:30 を使います。ネパールは45分オフセットの UTC+5:45 を使います。ニュージーランドのチャタム諸島は UTC+12:45 を使います。こうした非標準オフセットは、UTC から単に時間を数えるだけでは済まないことを意味します。各ゾーンの実際のオフセットが必要です。 夏時間（DST）は、春に時計を1時間進め、秋に1時間戻すことで変換を複雑にします。すべての国が DST を観測するわけではありません。米国、カナダ、ヨーロッパの大部分は観測しますが、アリゾナ（ナバホ・ネイションを除く）、ハワイ、大部分の熱帯の国は観測しません。DST を観測する南半球の国は、季節が逆であるため、北半球の国とは異なる日付に時計を動かします。オーストラリアは10月と4月に動かします。米国とカナダは3月と11月です。ヨーロッパは3月と10月です。 春の進める移行は現地時刻に空白を作ります。時計が午前2:00から午前3:00に動くと、午前2:00と3:00の間の1時間は存在しません。この日の午前2:30に予定された予約は起こりません。秋の戻す移行は重複を作ります。時計が午前2:00から午前1:00に戻ると、午前1:00と2:00の間の1時間は2回起こります。午前1:30のイベントは曖昧です。これはスケジュールシステム、交通時刻表、現地時刻を処理するあらゆるソフトウェアに実際の問題を引き起こします。 DST の移行日は UTC オフセットを一時的に変えます。米国東部時間は冬は UTC-5（EST）、夏は UTC-4（EDT）です。中央ヨーロッパ時間は冬は UTC+1（CET）、夏は UTC+2（CEST）です。ある地域が時計を動かしたが別の地域がまだ動かしていない数週間、両者の時間差は変動します。米国とヨーロッパの時間差は通常6時間ですが、移行週には5時間や7時間になります。固定差を想定せず、常に現在のオフセットを確認しましょう。 IANA タイムゾーンデータベース（tz データベースや Olson データベースとも呼ばれる）は、タイムゾーン規則の権威ある情報源です。America/New_York、Europe/London、Asia/Tokyo、Pacific/Auckland のような場所ベースの識別子を使います。これらの識別子は各地域のタイムゾーン変更、DST 移行、政治的境界調整の完全な履歴をエンコードします。このデータベースを参照するソフトウェアライブラリは、過去の日付を含め変換を正しく処理します。データベースはボランティアにより維持され、国がタイムゾーン規則を変更するたび年に数回更新されます。 特定時刻のゾーン間変換には3つの情報が必要です：元の時刻、元のゾーンの UTC オフセット、対象ゾーンの UTC オフセット。元のオフセットを引いて元の時刻を UTC に変換し、対象オフセットを加えます。米国東部（UTC-5）の午後3:00を日本標準時（UTC+9）に変換するには：午後3:00 -（-5時間）= UTC 午後8:00。UTC 午後8:00 + 9時間 = 翌日午前5:00 JST。14時間の差は、ニューヨークと東京の間でビジネス時間がほとんど重ならないため、電話の予定が難しいことを意味します。 頻繁な変換のための実用的ショートカット：自分のローカルゾーンと最もよくやり取りするゾーンとのオフセットを暗記しましょう。ニューヨークにいて、ロンドン（冬は5時間進み、夏は4時間進み）やサンフランシスコ（両者とも DST を観測するため年間を通じて3時間遅れ）の同僚と定期的に働く場合、暗算が素早くできます。これらのオフセットは自動的になるまでモニタのそばの付箋に書きましょう。 日付変更線の横断は丸1日を加減します。国際日付変更線を西向きに横断するときは1日加え、東向きのときは1日引きます。火曜午前10:00にロサンゼルスを出発し15時間後にシドニーに到着するフライトは、LA 時刻の水曜午前1:00にあたる時に到着しますが、シドニーは UTC+11 で LA は UTC-8、19時間差です。火曜午前10:00に19時間を加えると水曜午前5:00 シドニー時刻になります。日付変更はエラーではなく、地球の自転の現実の帰結です。 複数のタイムゾーンをまたぐ会議のスケジュールは、重複するビジネス時間を見つける必要があります。サンフランシスコ（UTC-8）、ロンドン（UTC+0）、ムンバイ（UTC+5:30）にメンバーがいるチームでは、合理的な労働時間の重なりは狭いです。サンフランシスコの午前8:00はロンドンの午後4:00、ムンバイの午後9:30。サンフランシスコの午前6:00はロンドンの午後2:00、ムンバイの午後7:30。実際には、誰かが常に不便な時間を取らなければなりません。同じ人や地域が常に被らないよう不便を交代するのが一般的な公平性戦略です。一部のチームは会議を録画し、困難なタイムゾーンの人々が非同期的に視聴できるようにします。 世界時計表示は複数のゾーンの現在時刻を同時に示します。デスクトップやスマートフォンのホーム画面に世界時計ウィジェットを置けば、よく連絡を取る相手のための変換計算の必要がなくなります。ほとんどの OS は複数のタイムゾーン時計の追加をサポートします。Slack、Microsoft Teams、Google カレンダーはスケジュール時に参加者の現地時刻を表示できます。 タイムゾーンの略語は曖昧で、正式なコミュニケーションでは避けるべきです。CST は米国中部標準時（UTC-6）、中国標準時（UTC+8）、キューバ標準時（UTC-5）のいずれをも意味し得ます。IST はインド標準時（UTC+5:30）、アイルランド標準時（UTC+1）、イスラエル標準時（UTC+2）のいずれをも意味し得ます。BST は英国夏時間またはバングラデシュ標準時を意味し得ます。混乱を避けるため、常に UTC オフセットを指定するか、完全なゾーン名を使いましょう。「3:00 PM EST」ではなく「3:00 PM UTC-5」または「3:00 PM Eastern Time」と書きましょう。 スケジューリング標準としての UTC は変換の混乱を排除します。多くの国際組織、航空、軍事作戦、サーバーログが UTC を排他的に使います。サーバーメンテナンスウィンドウが 02:00〜04:00 UTC と言えば、世界中のだれもが曖昧さなく現地時に変換できます。航空はすべてのフライト計画、航空交通管制通信、気象報告に UTC を使い、ズールー時刻（Z と略記）と呼びます。軍のタイムゾーンは、ズールーからの各時間オフセットに文字呼称（Alpha から Yankee まで、Juliet を飛ばす）を使います。 タイムゾーンを扱うプログラミングには慎重な処理が必要です。データベースのすべてのタイムスタンプを UTC で格納しましょう。表示層でのみ現地時に変換します。これにより、異なるゾーンのユーザーが同じデータを操作する際のエラーを防げます。手動のオフセット計算を書くのではなく、確立されたライブラリ（JavaScript の moment-timezone、Python の pytz や zoneinfo、Java の java.time）を使いましょう。DST 移行、うるう秒、過去のゾーン変更周辺のエッジケースは手動では複雑すぎます。 タイムゾーンに関連するよくあるプログラミングのバグには、すべての日に24時間あると仮定する（DST 移行の日は23または25時間）、タイムゾーンオフセットが整数時間だと仮定する（インドは +5:30、ネパールは +5:45）、DST 移行が世界中で同時刻に起こると仮定する、UTC ではなく現地時刻を格納する、明示的なタイムゾーン情報なしで日付文字列を解析する、などがあります。これらの仮定はいずれも一部のユーザーに一部の時間不正な結果をもたらします。 Unix タイムスタンプ（1970年1月1日 00:00:00 UTC からの秒数）は、タイムゾーンに中立な瞬間の表現方法です。タイムスタンプ 1700000000 は地球上どこでも同じ瞬間です。これを現地時に変換すると異なるゾーンで異なる時計の読みを与えますが、根底の瞬間は同一です。これがサーバーと API がタイムスタンプを Unix エポック値や明示的な UTC オフセット付きの ISO 8601 文字列（2026-03-21T15:30:00Z や 2026-03-21T10:30:00-05:00）として交換する理由です。 旅行計画には出発地と到着地の両方のタイムゾーンの理解が必要です。ニューヨークからロンドン（冬は5時間差）へ飛ぶとき、午後7:00に出発する7時間のフライトは翌日の現地午前7:00に到着します。体は午前2:00だと思っています。この不一致が時差ボケです。東向きの旅行（時間を失う）は西向きの旅行（時間を得る）よりひどい時差ボケを引き起こす傾向があります。一般的な回復の目安は1タイムゾーンにつき1日です。出発前に1日1時間ずつ睡眠スケジュールを調整すれば、長い旅行の時差ボケを減らせます。 タイムゾーンは金融市場、放送スケジュール、製品ローンチに影響します。ニューヨーク証券取引所は東部時間の午前9:30に開き、それはロンドンの午後2:30、ロサンゼルスの午前6:30、東京の午後10:30です。外国為替市場はシドニー、東京、ロンドン、ニューヨーカーのセッションを通じて太陽を追うため24時間開いています。太平洋時間の真夜中での世界的な製品ローンチは世界中で異なる時間にかかります：東部の午前3:00、ロンドンの午前8:00、東京の午後5:00。これらの関係を理解すれば、いつ行動するかを計画するのに役立ちます。 国際的な出荷の締め切りと契約上の義務は、どのタイムゾーンが適用されるかを指定しなければなりません。「3月31日までに納品」という契約は、当事者が異なるゾーンにいれば曖昧です。東京ですでに4月1日のとき、ロサンゼルスではまだ3月31日です。法的・財務的な締め切りには常に明示的なタイムゾーン参照を含めるべきです。多くの法的文書はこの曖昧さを避けるため UTC や指定された場所の現地時間を使います。 過去のタイムゾーン変更は驚くほど一般的です。国や地域は定期的に UTC オフセットを変更し、DST を採用または廃止し、DST 移行日を動かします。ロシアは過去数十年でタイムゾーン規則を何度も変更し、直近では2014年に DST の観測をやめ、一部の地域オフセットを調整しました。サモアは2011年12月30日を完全に飛ばし、主な貿易相手国のオーストラリアとニュージーランドに合わせるため UTC-11 から UTC+13 に移行しました。エジプトは DST について何度も反転しました。北朝鮮は2015年に独自のタイムゾーン（UTC+8:30）を作り、2018年に UTC+9 に戻しました。これらの変更は、過去の時間変換に現在の規則が使えないことを意味します。 夏時間の廃止は多くの地域で進行中の立法の努力です。米国上院は2022年に DST を通年恒久的にするサンシャイン保護法を可決しましたが、下院で停滞しました。欧州連合は2019年に季節的な時計変更の廃止を投票し、各加盟国に永続的な標準時または永続的な夏時間の選択を許可しましたが、実施は繰り返し先延ばしされています。アリゾナとハワイはすでに DST を観測しません。あなたの地域で DST が最終的に廃止された場合、依然として DST を観測する地域とのタイムゾーン変換には、どの地域が変更し、どの地域が変更しないかの追跡が必要です。 タイムゾーンをまたぐリモートワークには意図的なコミュニケーションの実践が必要です。一部の時間にとってピーク外であっても、全チームメンバーが利用可能と期待されるコア時間を設定しましょう。各ビューアーの現地時刻でイベントを表示する共有カレンダーを使いましょう。ライブで参加できない人のためにすべての会議を録画しましょう。非同期的なコミュニケーション（メール、チャット）について明確な応答時間の期待を設定しましょう。意思決定を文書化し、異なるゾーンのチームメンバーが自身のスケジュールで追いつけるようにしましょう。 タイムゾーンをまたぐスポーツ中継は、同じイベントが異なる時計の時刻で放送されることを意味します。東部時間の午後6:30にキックオフするスーパーボウルは、太平洋の午後3:30、GMT の午後11:30、東京の翌日午前8:30です。アジアやヨーロッパのホスト都市からの中継のオリンピックイベントは、アメリカの視聴者には真夜中に放送されます。タイムゾーンの計算を理解すれば、アラームを設定し、視聴パーティーを計画し、自分のゾーンでまだ放送されていないイベントのネタバレを避けるのに役立ちます。 eコマースとカスタマーサポートの営業時間は、グローバルビジネスではタイムゾーンにまたがります。インド（UTC+5:30）のサポートチームは米国の睡眠時間にチケットを処理し、24時間体制を提供します。セール開始時刻と販促の締め切りは、適用されるタイムゾーンを指定しなければなりません。PST の真夜中に終わるセールは、東海岸の顧客に西海岸の顧客より3時間少ない時間を与えます。賢いビジネスは、各訪問者のブラウザのタイムゾーンにローカライズされるカウントダウンタイマーを表示します。 電話の時差計算には、季節的に変わる可能性のある出発地と到着地の両方のオフセットを知る必要があります。ニューヨークからドバイ（UTC+4、DST なし）への電話は、冬（EST、UTC-5）は9時間差、夏（EDT、UTC-4）は8時間差です。よく連絡する相手のタイムゾーンと DST ステータスを載せた参照カードやアプリを持っていれば、真夜中の気まずい電話を防げます。 タイムゾーンをまたぐ医療予約と処方のタイミングには注意が必要です。自宅のタイムゾーンで午前8時と午後8時に12時間ごとに服用すべき薬は、旅行時に現地の時計に変更されるわけではありません。体の概日リズムは旅行の最初の数日間は自宅のタイムゾーンに従います。旅行中に1日1〜2時間ずつ服薬時刻をずらせば、一貫した投与間隔を維持できます。重要な薬（血液希釈剤、心臓の薬、インスリン）については、複数のタイムゾーンを越えて旅行する前に医師に相談しましょう。 オンライン試験と締め切りの監督はタイムゾーンにまたがります。東部時間の午前9:00に世界的なオンライン試験を提供する大学は、カリフォルニア（午前6:00）、ロンドン（午後2:00）、シンガポール（午後9:00）の学生に非常に異なる条件を作ります。公正な評価ポリシーは、複数の時間枠や24時間の提出期間を提供することでこれらの違いを考慮します。学生は常に締め切りがどのタイムゾーンを使うかを確認し、事前に現地時に変換すべきです。 タイムゾーンをまたぐサーバーとインフラの管理には標準的な実践が必要です。ログのタイムスタンプはサーバーの場所にかかわらず常に UTC にすべきです。Cron ジョブとスケジュールタスクは UTC を参照し、DST 関連の失敗を避けるべきです（現地の午前2:30に予定されたジョブは春の進める移行中にスキップされます）。データベースのタイムスタンプはタイムゾーンのメタデータ付きで UTC を格納すべきです。監視ダッシュボードは内部的に UTC を格納しながらビューアーの現地ゾーンで時刻を表示すべきです。これらの実践は、異なるゾーンのシステムが相互作用するときに生じる微妙なバグを防ぎます。 クルーズ船のタイムゾーンは航海中に変化します。複数のタイムゾーンを横断する大西洋横断クルーズは、選ばれた夜に船の時計を1時間調整します。船は午前2:00に時計を進めるまたは戻すことを告げるかもしれません。これは食事時間、エクスカーションのスケジュール、服薬のタイミングに影響します。港に停泊するとき、現地時刻は船の時刻と異なることがあります。エクスカーションとツアーでは、表示された時刻が船の時刻か港の時刻かを常に確認しましょう。 タイムゾーンをまたぐソーシャルメディアの投稿には、オーディエンスがいつアクティブかを知る必要があります。フォロワーが主に米国にいれば、東部時間の午前9:00の投稿は東海岸の朝の通勤時間に届きますが、西海岸にはスクロールする人が少ない午前6:00にかかります。Buffer や Hootsuite のようなスケジュールツールは特定のゾーンで投稿時刻を設定し、時間帯別のエンゲージメントを分析できます。グローバルなオーディエンスには、同じコンテンツを異なる時間に複数回投稿するか、タイミングを問わず良く機能する常緑コンテンツを使うことで、タイムゾーンの広がりに対処します。 タイムゾーンマップと可視化ツールは、オフセットの数値だけでは明らかでない地理的関係の理解に役立ちます。ロシアは11のタイムゾーン（UTC+2 から UTC+12）にまたがります。カナダは6つのタイムゾーンです。ブラジルは4。インドネシアは3。5つの地理的ゾーンにまたがるにもかかわらず中国全国が UTC+8 を使うことを知れば、中国西部で夏の日の入りが午後10時以降になる理由が説明できます。視覚的なタイムゾーンマップは、純粋なオフセット数値が伝えないこうした異常を明らかにします。 WebRecast のタイムゾーン変換ツールは、基準のタイムゾーンと対象のタイムゾーンを選び、時刻を入力すると変換結果を表示します。有効な DST 調整を含む現在の UTC オフセットを考慮します。国際電話のスケジュール、自分のタイムゾーンでのライブストリームの開始時刻の確認、分散チームをまたぐ締め切りの調整に使いましょう。ツールがオフセット計算を処理するため、どのゾーンが現在 DST を観測しているかを追跡する必要はありません。

関連ガイド

関連する WebRecast セクション