すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。
都市をリストに追加してください(ソウル・東京・ニューヨーク・ロンドン・サンフランシスコ — 同僚のいる場所など)。各都市の現在時刻がライブ表示され、上部のタイムスライダで 1 日をスクラブして全員に合う時間帯を探せます。各行には UTC オフセット、その都市が現在サマータイム中かどうか、ローカルタイムゾーンから見た日付(3 月 5 日午前 9 時のソウル枠が、サンフランシスコでは「3 月 4 日午後 7 時」と表示される — 同じ瞬間で別のカレンダー日付)も表示します。
タイムゾーンをまたぐ会議の調整、UTC タイムスタンプを吐くサーバログを現地時刻で考えたい場面、複数のタイムゾーンを跨ぐ航空便のある旅行計画などに使ってください。サマータイムの切り替えはブラウザが IANA tz database を介して処理します。`America/Los_Angeles` を選べば `PST` と `PDT` の切り替えが自動的に行われます。すべてがローカルで動作し、都市リストはアップロードされず、時計もサーバから取得しません。
cities: Seoul, Tokyo, San Francisco, New York, London slider: Seoul 09:00 (March 5)
Seoul 09:00 Wed Mar 5 Tokyo 09:00 Wed Mar 5 San Francisco 17:00 Tue Mar 4 (PST) New York 20:00 Tue Mar 4 (EST) London 01:00 Wed Mar 5 (UTC)
日付が変わっている点に注目してください。ソウルの水曜午前 9 時はサンフランシスコでは火曜の夕方、ロンドンでは水曜の午前 1 時です。グローバル会議で「全員に許容できる」スイートスポットは多くの場合ソウルの午後(米国東部の夕方、米国西部の午後)になります。タイムスライダで試してみてください。
cities: Tokyo, New York slider: New York 02:30 (March 8)
Tokyo 16:30 Sun Mar 8 New York invalid (DST spring-forward 02:00 → 03:00)
3 月第 2 日曜日、米国東部時間は 02:00 から 03:00 へ直接ジャンプします — その日の 02:30 は存在しません。本コンバータはこれを検出して「invalid」と表示し、02:30 EST か 02:30 EDT を黙って選ぶことはしません。逆の現象は 11 月第 1 日曜日に起きます。同じ日に 01:30 が 2 回(1 回目 EDT、2 回目 EST)出現し、これを曖昧としてフラグするツールもあれば、最初の出現を選ぶツールもあります。
cities: London (Europe/London), Lisbon (Europe/Lisbon) date: November 2
London UTC+00:00 (GMT, just exited BST) Lisbon UTC+00:00 (WET, just exited WEST)
2 つの都市は *今日* は同じオフセットでも、サマータイム規則が異なるため年の別の時期では違うことがあります。ロンドンは 10 月最終日曜日に BST(UTC+1)から GMT(UTC+0)に切り替わります。リスボンも同じ日に切り替わりますが名称が違います(WEST → WET)。11 月 2 日には両方 UTC+0 ですが、夏はロンドンが +1、リスボンも +1 です — シフトは同じでもラベルが異なります。略号ではなく IANA 名(`Europe/London`・`Europe/Lisbon`)で識別してください。
IANA 名は *規則を含むゾーン* を識別し、略号は *現在のオフセット* しか識別しません。`KST` は曖昧ではありませんが(韓国は 1988 年以降サマータイムなし)、`CST` は中国(UTC+8、DST なし)・米国中部(UTC−6 / −5、DST あり)・キューバ(UTC−5 / −4、DST あり)のいずれにもなり得ます。`BST` はヨーロッパでは英国夏時間ですが、アジアではバングラデシュ標準時です。`America/New_York` のような IANA 名はサマータイム全スケジュールと歴史的変更を保持するため、同じ文字列が今日も、1980 年も、将来の DST 政策変更後も正しく動作します。ゾーンは常に IANA 名で保存・受け渡しし、略号は表示時にのみレンダリングしてください。
国ごとに異なり、たまに変更されます。**米国 / カナダ**: 3 月第 2 日曜日(進む)と 11 月第 1 日曜日(戻る)。切り替えは現地 02:00。**EU / 英国**: 3 月最終日曜日と 10 月最終日曜日。切り替えは加盟国全体で 01:00 UTC。**オーストラリア**: 10 月第 1 日曜日と 4 月第 1 日曜日(南部州のみ実施)。**アジア・アフリカ・南米の大半**: サマータイムなし。韓国は 1988 年、日本は 1952 年に廃止し、中国はすべてを UTC+8 に統一しています。IANA tz database はおよそ 1970 年以降の規則変更を追跡し、それ以前の日付には歴史的推定値を提供します。
どちらも正しく、同じ瞬間ですがカレンダー日が異なります。`00:00 3 月 5 日` と `24:00 3 月 4 日` は同じ時刻です。ISO 8601 は人向け表示には `00:00` を好みますが、契約書での 1 日の終わりを示す境界には `24:00` を許可します(「この申し出は 3 月 4 日 24:00 で失効」と書けば、深夜が 3 月 5 日から始まるかの曖昧さなしに締切が明確になります)。精度が重要な場面では `12:00 AM` / `12:00 PM` 表記を避けてください。多くの人が真夜中と正午の AM / PM 割り当てを誤読します。24 時間制を使うか、明示的に「正午」「真夜中」と書いてください。
現代のブラウザ(Chrome / Edge / Safari 2023 以降)は最新の IANA tz database を組み込み、ブラウザリリースごとに(約 6 週間ごと)更新します。リリースサイクル以上前にアナウンスされた DST 規則変更は正しく動きますが、緊急変更(エジプトが数週間前の通告で何度か DST を中止)は 1〜2 リリースサイクル遅れることがあります。サーバ側で規則変更をより早く取り込みたい場合は、npm や pip から更新を取得するランタイム tz ライブラリを使ってください(`tzdata` パッケージは IANA リリース後数日内に更新を公開します)。
ペアで保存してください。ローカルの壁時計時刻(`2026-06-15 09:00`)と IANA ゾーン(`Asia/Seoul`)です。書き込み時に UTC へ変換 *してはいけません*。もし韓国が将来サマータイム規則を変更した場合(1988 年以降変更はありませんが、政府が再検討することはあり得ます)、保存済みの UTC 値が間違いになるためです。ローカル + ゾーンの組み合わせを UTC に変換するのはレンダリング時のみ、*現在の* tz データベースに対して行ってください。PostgreSQL では `timestamp` とゾーン用の別 `text` カラムを併用するか、`timestamptz` とゾーンカラムを併用するアプリもあります。繰り返しイベントにも同じ助言が当てはまります — UTC ではなく会議のホームゾーンで `RRULE:FREQ=WEEKLY;BYHOUR=9` を保存してください。
一部の国は 30 分や 15 分単位のオフセットを使い、これは 1972 年以前の標準化以前の歴史的遺物です。**インド**は UTC+05:30(国全体で 1 ゾーン、東西の経度差を中間で割っている)。**イラン**は UTC+03:30。**アフガニスタン**は UTC+04:30。**ネパール**は UTC+05:45(現在常用される唯一の 15 分単位ゾーンで、インドから 15 分ずらした設定)。**チャタム諸島**(ニュージーランド)は UTC+12:45 / 13:45。IANA tz database はこれらすべてを正しく扱います。IANA 名で識別してください(`Asia/Kolkata`・`Asia/Tehran`・`Asia/Kathmandu`・`Pacific/Chatham` など)。
タイムゾーンとは、UTC からの壁時計オフセットと、もしあるなら 1 時間ずらすサマータイムのルール集合に合意した地域のことです。**IANA tz database**(Olson database とも呼ばれ、1986 年に開始した Arthur David Olson にちなむ)はこれらの規則の正本です。あらゆる現代の OS とランタイムが何らかの形でこれを同梱しています — Linux の `/usr/share/zoneinfo`、macOS の `/var/db/timezone`、Windows の ICU バンドル、Node.js の `Intl.DateTimeFormat` など。データベースはゾーンを政治的境界ではなく `Continent/City`(例: `Asia/Seoul`、`America/New_York`、`Europe/Berlin`)で識別します。一国内でも規則が分かれることがあるためです。
**瞬間とローカル時刻の分離** が核となる抽象です。`1741132800` のような Unix タイムスタンプは絶対的な瞬間で、地球上のどこでも同じ時です。その瞬間を壁時計時刻として表示する方法は問い合わせたゾーンに依存します — `2025-03-05 09:00 KST` と `2025-03-04 16:00 PST` は同じ瞬間です。この区別を混同するのが、ほとんどのカレンダーバグの原因です。原則は、過去のイベントは UTC で瞬間を保存し、将来のイベントは `(local_time, zone)` で保存することです。将来のイベントについては、開催前にゾーンの規則が変更される可能性があるためです。
隣接する 3 つの考え方があります。**UTC**(協定世界時)はグローバルな基準で、オフセットはこれに対して表現されます。**うるう秒** は UTC に時折加えられる 1 秒の調整で、最後に適用されたのは 2016 年 12 月です。Unix 時刻は意図的にこれを無視しますが、TAI や GPS 時刻はカウントするため、2026 年時点でオフセットは 37 秒離れています。うるう秒を廃止する(2035 年以降)国際会議が進行中です。**サマータイム政策** は本当に混沌としています — ロシアは 2011 年に廃止、EU は 2019 年から「もうすぐ廃止する」状態が続き、ブラジルは 2019 年に廃止、米国の多くの州で法案が審議中です。将来の DST に関するあらゆる仮定を脆弱とみなし、tz データベースを唯一の信頼できる情報源として頼り、定期的に更新してください。
西暦と元号(明治・大正・昭和・平成・令和)を相互変換。元年の改元日(平成元年 1989-01-08、令和元年 2019-05-01 など)を正確に処理。
クラシックな 25 / 5 / 15 分のポモドーロタイマー。ブラウザ通知に対応、localStorage で完了セッション数を記録。サインアップ・トラッキング無し。
西暦から十二支(子・丑・寅・卯…)と六十干支を表示。中国語・日本語・韓国語の正式名称を併記。
Unix タイムスタンプと ISO 8601 を相互変換。ローカル / UTC・相対表記の表示、入力に即時反映。
