YourWorldTime

タイムゾーン変換

二つのタイムゾーンと日付を選ぶだけで正確に変換します。夏時間の切り替えによってその地方時が存在しない日、あるいは二度訪れる日でも同じです。

時刻を変換する

変換後の時刻

次の変更

オフセットと日付はビルド時にIANAデータベースから算出しています。実時間の表示はブラウザ内で描画されます。

変換元UTC次の変更
New YorkUTC-42026-11-01 時計を60分戻します
Los AngelesUTC-72026-11-01 時計を60分戻します
LondonUTC+12026-10-25 時計を60分戻します
BerlinUTC+22026-10-25 時計を60分戻します
KolkataUTC+5:30夏時間を実施しない
TokyoUTC+9夏時間を実施しない
SingaporeUTC+8夏時間を実施しない
SydneyUTC+102026-10-04 時計を60分進めます

タイムゾーン変換が狂う原因

日程調整の失敗はほぼ四つの原因のどれかから生まれます。ここではその四つを、丸めて済ませるのではなく正面から扱っています。

オフセットは定数ではありません。「ニューヨークはロンドンより5時間遅い」は一年のうち約十か月しか正しくありません。春に約三週間、秋に約一週間は4時間差になります。両地域が別々の日付で時計を動かすからです。都市ごとに固定のオフセットを保存している変換ツールは、まさにその日々に間違えます。そして人が後悔する会議を入れてしまうのも、ちょうどその日々なのです。

すべてのオフセットが正時とはかぎりません。インドはUTCより5時間30分進んでいます。ネパールは5時間45分。チャタム諸島は12時間45分進み、ロードハウ島は夏時間開始時にわずか30分しか動きません。世界のおよそ五分の一は、正時ではないオフセットの上で暮らしています。

存在しない地方時があります。時計が進むとき、一時間が消えます。ニューヨークでは切り替え日に01:59:59の直後が03:00:00となり、02:30は決して訪れません。多くのツールに02:30の変換を求めれば、それでも自信ありげに答えを返します。このツールは、自分が何をしたのかを伝えます。

二度訪れる地方時もあります。時計が戻るとき、一時間が繰り返されます。01:30は夏時間で一度、その一時間後に標準時でもう一度訪れます。この変換ツールは最初の方を採用し、そのことを明示したうえで、二度目も併せて示します。

よくある質問

この変換ツールは夏時間に対応していますか。
しています。切り替え当日の厄介な二日間にも対応します。オフセットはブラウザ経由でIANAデータベースから取得するため、切り替え日の変換にはその瞬間に実際に適用されていたオフセットが使われ、今日のオフセットは使いません。存在しなかった地方時や、二度訪れた地方時を入力した場合は、黙ってどちらかを選ぶのではなく、そう表示します。
二つの都市の時差が一年のうちに変わるのはなぜですか。
二つの地域が同じ日に時計を動かすことはまれで、まったく動かさない地域もあるからです。ニューヨークは一年の大半でロンドンより5時間遅れていますが、3月の二週間だけは4時間遅れになります。アメリカがヨーロッパより二、三週間早く時計を進めるためです。記憶したオフセットではなく、必ず具体的な日付に対して変換してください。
どのタイムゾーン間で変換できますか。
IANAデータベースにあるすべて、400を超えるタイムゾーンです。多くの変換ツールがつまずく30分・45分単位のオフセットも含みます。UTC+05:30のインド、UTC+05:45のネパール、UTC+12:45のチャタム諸島も、最も近い時間に丸めることなく正確に扱います。
JavaScriptは必要ですか。
リアルタイムで動く変換部分には必要です。それ以外のすべて、つまりオフセット、夏時間の切り替え日、一時間ごとの一覧表、あらゆる解説は、あらかじめ生成されたページの一部であり、JavaScriptを無効にしていても機能します。
ここに入力した内容はどこかへ送られますか。
いいえ。計算はすべてブラウザ内で行われます。バックエンドも、アクセス解析も、Cookieも、第三者スクリプトもありません。選んだタイムゾーンは変換結果を共有・ブックマークできるようURLに現れますが、行き先はそこだけです。