日時の処理は、地味に見えてバグの温床です。「9時間ズレる（JSTとUTCの混同）」「夏時間で1時間ずれる」「ローカル時刻のまま保存してサーバーとクライアントで食い違う」「ミリ秒と秒を取り違える」——どれも実務でよく起きます。基本方針はシンプルで、**保存・比較はUTC（またはUnixタイムスタンプ）で行い、ユーザーに見せる瞬間だけローカルのタイムゾーンに変換する**こと。この記事では、その原則を実際のツールで確認しながら、タイムスタンプの変換・タイムゾーンの変換・期間の計算という3つの場面を順番に見ていきます。
1. Unixタイムスタンプと日時を相互変換して確認する
Unixタイムスタンプ（エポック秒）は「協定世界時1970年1月1日からの経過秒数」で、タイムゾーンを持たない絶対時刻です。だからログやDB、API間のやり取りでは、この形で持つと食い違いが起きません。タイムスタンプコンバーターに数値を入れると、対応する日時とタイムゾーンごとの表示を確認できます。ここでの定番の落とし穴が「秒とミリ秒」の取り違えです。JavaScriptのDate.now()はミリ秒、多くのバックエンドは秒を使うため、桁数（10桁＝秒、13桁＝ミリ秒）を必ず確認しましょう。保存されたタイムスタンプが意図した日時かを、まずここで答え合わせします。
この手順で使うツール
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 / Time Calculator
日付の差分計算・日数加算・営業日カウントが1画面で
まとめ
日時のバグは「保存・比較はUTC（Unixタイムスタンプ）、表示のときだけローカルに変換」という原則を徹底するだけで大きく減らせます。保存時にローカル時刻の文字列をそのまま入れない、比較はエポック秒で行う、変換はタイムゾーン名ベースで夏時間を考慮する、ミリ秒と秒を取り違えない——この4点を押さえておけば、9時間ズレや夏時間ずれといった典型的な事故を防げます。迷ったらまずタイムスタンプに直して絶対時刻で考える、を習慣にしましょう。