なぜ「タイムゾーン取得」ユーティリティが業務で重要なのか
業務システムで日付や時刻を扱うとき、必ず出てくるのが「タイムゾーン」の問題です。
日本のユーザーと海外のユーザーが混在していたり、サーバーは UTC、ユーザーは JST だったりします。
「サーバーでは UTC で保存して、画面ではユーザーのタイムゾーンで表示したい」
「メールの送信予定時刻を、ユーザーの現地時間で設定したい」
「ログを見たときに、“その人の時間”で何時だったかを知りたい」
こういうときに必要になるのが、
「今このブラウザ（ユーザー）は、どのタイムゾーンにいるのか」
を取得するユーティリティです。
ブラウザでタイムゾーンを取得する基本
Intl.DateTimeFormat を使ったタイムゾーン取得
今のブラウザでは、Intl.DateTimeFormat という国際化 API を使うことで、
ユーザーのタイムゾーンをかなり簡単に取得できます。
一番シンプルな例はこれです。
const tz = Intl.DateTimeFormat().resolvedOptions().timeZone;
console.log(tz); // 例: "Asia/Tokyo", "America/New_York"
timeZone には、"Asia/Tokyo" や "Europe/London" のような「IANA タイムゾーン名」が入ります。
この文字列は、サーバーサイド（Java / Node.js / Python など）でもよく使われる形式なので、
「フロントで取得 → サーバーに渡す → サーバーで変換・保存」
という流れが作りやすいのが大きなメリットです。
タイムゾーン取得ユーティリティの基本形
安全にラップしておく
生の API をそのままアプリのあちこちで使うのではなく、
小さなユーティリティにまとめておくと扱いやすくなります。
function getTimeZone() {
if (typeof Intl === "undefined" || !Intl.DateTimeFormat) {
return "UTC";
}
const options = Intl.DateTimeFormat().resolvedOptions();
if (!options.timeZone) {
return "UTC";
}
return options.timeZone;
}
ここでのポイントは三つです。
Intl が使えない古い環境では、安全に "UTC" を返すようにしていること。resolvedOptions().timeZone が取れなかった場合も "UTC" にフォールバックしていること。
アプリ本体は getTimeZone() だけを呼べばよく、細かい条件分岐を意識しなくていいこと。
使い方はとてもシンプルです。
const tz = getTimeZone();
console.log("ユーザーのタイムゾーン:", tz);
タイムゾーンをどう使うか（実務的な例）
例1: サーバーに「ユーザーのタイムゾーン」を送る
例えば、ユーザーが「2026-02-13 10:00 に通知して」と設定したとします。
このとき、サーバー側で正しく扱うには、
ユーザーが入力した「ローカル時間」
ユーザーのタイムゾーン（例: “Asia/Tokyo”）
の両方が必要になります。
フロント側では、こういうイメージになります。
const tz = getTimeZone();
const payload = {
notifyAt: "2026-02-13T10:00:00", // ユーザー入力（ローカル時間）
timeZone: tz, // 例: "Asia/Tokyo"
};
fetch("/api/notifications", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify(payload),
});
サーバー側は、notifyAt と timeZone を組み合わせて
UTC に変換して保存したり、ジョブをスケジュールしたりできます。
ここでの重要ポイントは、
「フロントで“何時”だけではなく、“どのタイムゾーンの何時か”も一緒に渡す」
という設計にすることです。
例2: UTC の日時をユーザーのタイムゾーンで表示する
サーバーが UTC で日時を返してくるケースはよくあります。
{
"createdAt": "2026-02-13T09:00:00Z"
}
これをユーザーのタイムゾーンで表示したいとき、getTimeZone() と Intl.DateTimeFormat を組み合わせるときれいに書けます。
const tz = getTimeZone();
function formatDateTimeUtcToLocal(utcString) {
const date = new Date(utcString);
return new Intl.DateTimeFormat("ja-JP", {
timeZone: tz,
year: "numeric",
month: "2-digit",
day: "2-digit",
hour: "2-digit",
minute: "2-digit",
}).format(date);
}
const text = formatDateTimeUtcToLocal("2026-02-13T09:00:00Z");
console.log(text); // 例: "2026/02/13 18:00"（タイムゾーンによって変わる）
ここでの深掘りポイントは、
Date オブジェクト自体は「UTC ベースの瞬間」を表していること。Intl.DateTimeFormat に timeZone を渡すことで、「どのタイムゾーンとして表示するか」を指定できること。
つまり、
「保存は UTC、表示はユーザーのタイムゾーン」
という王道パターンを、フロント側だけで完結して実現できるわけです。
タイムゾーン取得を直接あちこちでやらない理由
初心者がやりがちなのは、画面のあちこちでこう書いてしまうことです。
Intl.DateTimeFormat().resolvedOptions().timeZone
これをいろんなファイルに散らばせると、
フォールバックの仕様を変えたくなったとき
「一部の環境では timeZone が取れない」問題に対応したくなったとき
に、全部探して直す必要が出てきます。
それを避けるために、
タイムゾーン取得は必ず getTimeZone() を通す
アプリ本体は「タイムゾーン名の文字列」だけを受け取る
という構造にしておくことが、業務コードとしてとても重要です。
小さな練習で感覚をつかむ
ブラウザのコンソールで、次のように打ってみてください。
Intl.DateTimeFormat().resolvedOptions()
返ってきたオブジェクトの中に、timeZone というプロパティがあるはずです。
そこに "Asia/Tokyo" や "America/Los_Angeles" のような文字列が入っています。
それを見ながら、
自分の環境のタイムゾーン名が何になっているかgetTimeZone() を書き換えたらどう振る舞いが変わるか
を試してみると、「タイムゾーン取得ユーティリティ」が
単なるおまけではなく、
「日付・時刻の設計の入り口」になっていることが実感できるはずです。