日時の処理は、地味に見えてバグの温床です。「9時間ズレる（JSTとUTCの混同）」「夏時間で1時間ずれる」「ローカル時刻のまま保存してサーバーとクライアントで食い違う」「ミリ秒と秒を取り違える」——どれも実務でよく起きます。基本方針はシンプルで、「保存・比較はUTC（またはUnixタイムスタンプ）で行い、ユーザーに見せる瞬間だけローカルのタイムゾーンに変換する」こと。この記事では、その原則を実際のツールで確認しながら、タイムスタンプの変換・タイムゾーンの変換・期間の計算という3つの場面を順番に見ていきます。
1. Unixタイムスタンプと日時を相互変換して確認する
Unixタイムスタンプ（エポック秒）は「協定世界時1970年1月1日からの経過秒数」で、タイムゾーンを持たない絶対時刻です。だからログやDB、API間のやり取りでは、この形で持つと食い違いが起きません。タイムスタンプコンバーターに数値を入れると、対応する日時とタイムゾーンごとの表示を確認できます。ここでの定番の落とし穴が「秒とミリ秒」の取り違えです。JavaScriptのDate.now()はミリ秒、多くのバックエンドは秒を使うため、桁数（10桁＝秒、13桁＝ミリ秒）を必ず確認しましょう。保存されたタイムスタンプが意図した日時かを、まずここで答え合わせします。JavaScript には、文字列から日時を作るときの落とし穴もあります。`new Date('2026-10-24')` のように日付だけを渡すとUTCの0時として読まれますが、`new Date('2026-10-24T00:00')` のように時刻を付けるとブラウザの時刻帯の0時として読まれます。前者で作った日付の曜日を `getDay()` で読むと、アメリカ西海岸の時刻帯では金曜日の23日になりました。逆向きの `toISOString().slice(0, 10)` で「今日の日付」を作るのも危険で、日本では朝9時より前に実行すると前日の日付になります。
この手順で使うツール
Timestamp Converter
Unix タイムスタンプ ↔ 日時 リアルタイム変換
2. タイムゾーンをまたいで時刻を変換する
「東京の15時はサンフランシスコでは何時か」のように、複数のタイムゾーンをまたぐ時刻はミスが起きやすい領域です。タイムゾーンコンバーターで複数都市を並べると、同じ瞬間が各地で何時になるか、ビジネスアワーが重なる時間帯はどこかを一目で確認できます。特に注意すべきは夏時間（DST）で、同じ「アメリカ東部時間」でも時期によってUTCとの差が変わります。UTCとの固定オフセット（例: +9:00）で決め打ちすると夏時間のある地域でずれるため、時刻の変換は必ずタイムゾーン名（Asia/Tokyo など）ベースで扱うのが安全です。会議設定や通知の配信時刻を決めるときに役立ちます。
この手順で使うツール
Time Zone Converter
最大5都市のタイムゾーンを同時変換・ビジネスアワー重複をビジュアル表示
3. 期間・差分・営業日を計算する
2つの日時の差、締め切りまでの残り日数、N営業日後といった計算も、日時処理の定番です。日時計算ツールで差分・日数加算・営業日カウントを行えば、手計算やスプレッドシートでのミスを避けられます。ここでもタイムゾーンと夏時間は影響します。たとえば夏時間の切り替え日をまたぐと1日が23時間や25時間になり、「24時間 = 1日」という前提の単純計算がずれることがあります。厳密な期間計算では、まずUTCで日数を出し、表示のときにローカルへ変換する、という順序を守ると安全です。営業日の計算では、土日だけでなく祝日も除く必要があります。Date Calculator の営業日カウントと「N営業日後」は、日本の祝日（振替休日・国民の休日を含む）も除いて数えられます。たとえば2026年9月18日〜25日は8日間のうち、土日だけを除くと6営業日ですが、敬老の日・国民の休日・秋分の日が続くため、祝日も除くと3営業日しかありません。なお、年末年始や会社独自の休業日は祝日ではないので、締め切りの計算では別に考える必要があります。
この手順で使うツール
Date / Time Calculator
日付の差分計算・日数加算・営業日カウントが1画面で
まとめ
日時のバグは「保存・比較はUTC（Unixタイムスタンプ）、表示のときだけローカルに変換」という原則を徹底するだけで大きく減らせます。保存時にローカル時刻の文字列をそのまま入れない、比較はエポック秒で行う、変換はタイムゾーン名ベースで夏時間を考慮する、ミリ秒と秒を取り違えない——この4点を押さえておけば、9時間ズレや夏時間ずれといった典型的な事故を防げます。迷ったらまずタイムスタンプに直して絶対時刻で考える、を習慣にしましょう。