ToolDeck

タイムゾーン変換

世界中のタイムゾーン間で日時を変換する

UTCUTC+00:00

04/16/2026, 21:56:00

America/New_YorkUTC-04:00

04/16/2026, 17:56:00

タイムゾーン変換とは?

タイムゾーン変換ツールは、ある日時を一つのタイムゾーンから別のタイムゾーンに変換し、世界のどこでも対応する時刻を即座に確認できるようにするものです。世界は24の主要タイムゾーンに分かれており、それぞれが協定世界時(UTC)からの固定オフセットとして定義されています。UTC 14:00の場合、ニューヨーク(UTC-5)では09:00、東京(UTC+9)では23:00になります。タイムゾーン間を正確に変換するには、変換元・変換先のUTCオフセットと、いずれかで夏時間(DST)が適用されているかを把握する必要があります。

IANAタイムゾーンデータベース(Olsonデータベースまたはtzデータベースとも呼ばれる)は、オペレーティングシステム、プログラミング言語、Webブラウザが使用するタイムゾーン定義の標準ソースです。各タイムゾーンにはAmerica/New_YorkやAsia/Tokyoのようなリージョン/都市形式の正式識別子が割り当てられています。ESTやPSTのような略称とは異なり、IANA識別子は各地域のUTCオフセットの変更履歴とDST移行の全履歴を記録しており、過去・未来の日付にわたって正確に時刻を変換できる唯一の信頼できる方法です。

このタイムゾーン変換ツールは、ブラウザのJavaScriptエンジンにIntl APIを通じて組み込まれたIANAタイムゾーンデータを使用しています。変換元のタイムゾーンを選択して日時を入力すると、夏時間の調整を含む変換先タイムゾーンの対応時刻が即座に計算されます。すべての処理がブラウザ内で完結するため、サーバーへの通信は発生せず、データがデバイスの外に出ることもありません。

このタイムゾーン変換ツールを使う理由

タイムゾーンの計算を手動で行うのは、特に夏時間が絡む場合にミスが発生しやすい作業です。1月にUTC-5だった都市が7月にはUTC-4になることがあり、移行日は国によって異なります。米国と欧州では異なる日曜日に時計を切り替えるため、2週間の期間中はニューヨークとロンドンのオフセット差が年間の他の期間と異なります。このツールは、オペレーティングシステムが使用するのと同じIANAデータベースを用いて、こうした移行をすべて自動的に処理します。

~
即時変換
2つのタイムゾーンを選択して時刻を入力するだけで、結果が即座に表示されます。送信ボタンも再読み込みも不要。入力に合わせてリアルタイムに変換結果が更新されます。
~
DST対応の変換結果
夏時間の切り替えを自動的に考慮します。ブラウザ組み込みのIANAタイムゾーンデータを使用するため、過去・未来を問わず入力した日付に対して正しいオフセットが反映されます。
~
プライバシー優先の処理
すべての変換はIntl APIを使用してブラウザ内でローカルに実行されます。日時やタイムゾーンの選択情報がサーバーに送信されることはありません。
~
アカウント不要
アカウント登録、ソフトウェアのインストール、権限の許可は一切不要です。ページを開いて時刻を変換し、閉じるだけです。

タイムゾーン変換ツールの使用例

チームをまたいだスケジューリング
東京、ベルリン、シンガポールにまたがるチームで全員に都合のよいミーティング時間を見つけるには、3つ以上のタイムゾーンをまたいで変換する必要があります。自分のローカルタイムゾーンで候補時刻を入力し、各チームメンバーの所在地での対応時刻が勤務時間内かどうかを即座に確認できます。
APIタイムスタンプのデバッグ
APIレスポンスにはUTCやサーバーローカルのタイムゾーンでタイムスタンプが含まれることがよくあります。それらのタイムスタンプをローカル時刻に変換することで、イベントが期待通りのタイミングで発生しているか、時間ベースのロジックが正しいかを確認できます。
DevOpsインシデントのタイムライン構築
インシデント発生時、異なるリージョンのサーバーからのログエントリにはそれぞれ異なるタイムゾーンのタイムスタンプが含まれます。すべてのタイムスタンプを単一の基準タイムゾーン(通常はUTC)に変換することで、イベントの正確なタイムラインを構築できます。
日付ロジックのQAテスト
異なるリージョンのユーザーに日付を表示するアプリケーションは、特定のタイムゾーン入力でテストする必要があります。DSTの春の切り替え時刻といったエッジケースのテストシナリオを生成するのに、このツールを活用できます。
データパイプラインの調整
あるタイムゾーンでスケジュールされたETLジョブが、別のタイムゾーンにあるデータソースや下流処理のスケジュールと合わせる必要がある場合があります。スケジュールされた実行時刻を変換して、パイプラインの各ステージが正しい順序で実行されるかを確認できます。
タイムゾーンの概念を学ぶ
UTCオフセット、日付変更線、夏時間のルールを学ぶ学習者は、さまざまなタイムゾーンの組み合わせを試して、地域をまたいで時刻がどのように変化するかを確認できます。

IANAタイムゾーン参照テーブル

IANAタイムゾーンデータベースには400以上のタイムゾーン識別子が定義されており、政治的変更、新しいDSTルール、歴史的修正を反映するため年に数回更新されます。以下の表に最もよく使用されるタイムゾーンとその標準UTCオフセットおよびDSTの動作を示します。表示されているオフセットは標準時のものであり、DST列はその地域で夏時間が有効な期間の調整後オフセットを示しています。

IANA識別子一般名称UTCオフセットDST
UTCCoordinated Universal Time+00:00No
America/New_YorkEastern Time (US)-05:00Yes (EDT -04:00)
America/ChicagoCentral Time (US)-06:00Yes (CDT -05:00)
America/DenverMountain Time (US)-07:00Yes (MDT -06:00)
America/Los_AngelesPacific Time (US)-08:00Yes (PDT -07:00)
Europe/LondonGreenwich Mean Time+00:00Yes (BST +01:00)
Europe/BerlinCentral European Time+01:00Yes (CEST +02:00)
Europe/MoscowMoscow Time+03:00No
Asia/DubaiGulf Standard Time+04:00No
Asia/KolkataIndia Standard Time+05:30No
Asia/ShanghaiChina Standard Time+08:00No
Asia/TokyoJapan Standard Time+09:00No
Australia/SydneyAustralian Eastern Time+10:00Yes (AEDT +11:00)
Pacific/AucklandNew Zealand Standard Time+12:00Yes (NZDT +13:00)

コード例

主要なプログラミング言語はすべてIANAデータベースを通じたタイムゾーン変換機能を提供しています。以下の例では、JavaScriptのIntl APIを使用したUTCタイムスタンプの変換、Pythonのzoneinfoモジュール、Goのtimeパッケージ、シェルスクリプト用のGNU dateコマンドの使い方を示します。

JavaScript (Intl API)
// Convert a date from one timezone to another
const date = new Date('2026-03-15T09:00:00Z')

// Format in specific timezone
const nyTime = date.toLocaleString('en-US', { timeZone: 'America/New_York' })
// → "3/15/2026, 5:00:00 AM"

const tokyoTime = date.toLocaleString('en-US', { timeZone: 'Asia/Tokyo' })
// → "3/15/2026, 6:00:00 PM"

// Get the UTC offset for a timezone programmatically
function getUtcOffset(tz: string, date = new Date()) {
  const fmt = new Intl.DateTimeFormat('en-US', {
    timeZone: tz,
    timeZoneName: 'longOffset',
  })
  const parts = fmt.formatToParts(date)
  return parts.find(p => p.type === 'timeZoneName')?.value ?? ''
}
getUtcOffset('Asia/Kolkata') // → "GMT+05:30"
Python (zoneinfo + datetime)
from datetime import datetime
from zoneinfo import ZoneInfo

# Create a timezone-aware datetime
dt = datetime(2026, 3, 15, 9, 0, tzinfo=ZoneInfo('UTC'))

# Convert to New York time
ny = dt.astimezone(ZoneInfo('America/New_York'))
print(ny)  # → 2026-03-15 05:00:00-04:00 (EDT in March)

# Convert to Tokyo time
tokyo = dt.astimezone(ZoneInfo('Asia/Tokyo'))
print(tokyo)  # → 2026-03-15 18:00:00+09:00

# Get current time in any timezone
now_berlin = datetime.now(ZoneInfo('Europe/Berlin'))
print(now_berlin.strftime('%Y-%m-%d %H:%M %Z'))  # → 2026-03-15 10:00 CET
Go
package main

import (
	"fmt"
	"time"
)

func main() {
	utc := time.Date(2026, 3, 15, 9, 0, 0, 0, time.UTC)

	// Load timezone by IANA name
	ny, _ := time.LoadLocation("America/New_York")
	tokyo, _ := time.LoadLocation("Asia/Tokyo")

	fmt.Println(utc.In(ny))    // → 2026-03-15 05:00:00 -0400 EDT
	fmt.Println(utc.In(tokyo)) // → 2026-03-15 18:00:00 +0900 JST

	// Get the UTC offset in seconds
	_, offset := utc.In(ny).Zone()
	fmt.Printf("UTC offset: %+d hours\n", offset/3600) // → UTC offset: -4 hours
}
CLI (GNU date / TZ variable)
# Display current time in a specific timezone
TZ='Asia/Tokyo' date '+%Y-%m-%d %H:%M:%S %Z'
# → 2026-03-15 18:00:00 JST

# Convert a UTC timestamp to another timezone
TZ='America/Los_Angeles' date -d '2026-03-15T09:00:00Z' '+%Y-%m-%d %H:%M %Z'
# → 2026-03-15 02:00 PDT

# List all available IANA timezone names
timedatectl list-timezones | head -20

よくある質問

UTCとGMTの違いは何ですか?
UTC(協定世界時)とGMT(グリニッジ標準時)は、実用上は同じ時刻を表します。どちらも本初子午線からのオフセットがゼロです。違いは技術的なものです。UTCは原子時計によって定義され、コンピューティングで使用される世界標準時です。GMTは英国に結びついたタイムゾーン名です。コードでは、GMTではなくUTCを基準点として使用してください。
夏時間はタイムゾーン変換にどう影響しますか?
夏時間を採用している地域では、年間の一部においてUTCオフセットが1時間(時に30分または45分)ずれます。たとえば、America/New_Yorkは冬季がUTC-5(EST)、夏季がUTC-4(EDT)です。IANA識別子ではなく固定オフセットをハードコードすると、変換結果が年の半分で誤ったものになります。America/New_Yorkのような完全なIANA名を使用し、固定オフセットは避けてください。
ESTやPSTのような略称ではなくIANAタイムゾーン名を使うべき理由は?
タイムゾーンの略称は曖昧です。CSTはCentral Standard Time(UTC-6)、China Standard Time(UTC+8)、Cuba Standard Time(UTC-5)のいずれも意味し得ます。America/Chicagoのようなイアナ識別子はグローバルに一意であり、その地域のオフセット変更履歴とDSTルールをすべて記録しています。IANAデータベースはInternet Assigned Numbers Authorityが管理し、年に数回更新されます。
DSTの春の切り替えによるギャップに当たる時刻はどうなりますか?
時計が進められると、1時間がスキップされます。たとえばAmerica/New_Yorkでは、3月の第2日曜日に午前2:00が直接午前3:00になります。その日のそのタイムゾーンでは午前2:30という時刻は存在しません。ほとんどのプログラミング言語は、ライブラリによって異なりますが、この時刻を午前3:00に前進させるか、エラーを発生させることで処理します。
過去の日付に対して正確に変換できますか?
IANAタイムゾーン識別子を使用すれば可能です。IANAデータベースには数十年前までさかのぼる過去のオフセット変更が記録されています。たとえば、中国は1949年以前は5つのタイムゾーンを使用しており、その後単一のゾーン(UTC+8)に統一されました。データベースにはこれらの移行が記録されているため、Asia/Shanghaiの1945年のタイムスタンプを変換すると正しい歴史的オフセットが使用されます。
タイムゾーンの問題を避けるためにデータベースで時刻をどのように保存すべきですか?
すべてのタイムスタンプをUTCで保存してください。ユーザーに時刻を表示する際は、描画時にUTCからユーザーのローカルタイムゾーンに変換します。このアプローチは曖昧さを排除します。UTCタイムスタンプはサーバーやユーザーの所在地に関わらず一意の意味を持ちます。PostgreSQLのTIMESTAMPTZ型とMySQLのTIMESTAMP型はどちらも内部的にUTCで値を保存します。
30分や45分単位のオフセットを持つタイムゾーンはありますか?
あります。インド標準時(Asia/Kolkata)はUTC+5:30、ネパール標準時(Asia/Kathmandu)はUTC+5:45、チャタム諸島(Pacific/Chatham)はUTC+12:45です。イラン(Asia/Tehran)はUTC+3:30を使用しています。これらの端数オフセットが存在するため、変換ロジックを記述する際にすべてのタイムゾーン差が整数時間単位であると仮定することはできません。