日時が9時間ずれる原因と直し方｜Java・JS・MySQL・PG・Docker

日時がちょうど9時間ずれるのは、日本時間（JST＝UTC+9）とUTC（協定世界時）がどこかで入れ替わっているからです。 原因は次の2つのどちらかに分けられます。

1. どこかの層がUTCで動いている（サーバー・コンテナ・JVM・DBの設定がUTCのまま）
2. UTCの値をJSTとして、またはJSTの値をUTCとして読んでいる（タイムゾーンを持たない型で受け渡し、受け取った側が別のタイムゾーンで解釈した）

日時は「OS → コンテナ → アプリ（Java・Python・Node.js）→ ドライバ（JDBC など）→ DB → JSON → ブラウザ」と何層も通るため、どの層でずれたかを見つけることが一番の近道です。この記事では、各層でずれを実際に起こし、出た値と直し方を並べました。

確認環境：Ubuntu 24.04（OSのタイムゾーンはUTC）、OpenJDK 21.0.10、PostgreSQL 16.15＋PostgreSQL JDBC Driver 42.7.2、MySQL 8.0.46、Node.js 22、Python 3.13、Docker 29.4.3（確認日 2026年10月10日）。MySQL Connector/J の設定は、MySQL公式マニュアルと Connector/J 9.7.0 のソースに書かれた既定値で確認しています。

ずれの向きで原因を絞る

まず3か所の「今の時刻」を並べる

どの層がUTCで動いているかは、同じ瞬間に3か所の時刻を出すと分かります。

3か所のうち1か所だけUTCなら、そこが原因です。 すべてJSTなのにずれる場合は、値の受け渡し（型・ドライバ・JSON）でずれています（例5・7）。

例1：サーバー・コンテナのタイムゾーンがUTC

クラウドのサーバーやDockerのコンテナは、既定でUTCです。この記事の確認環境も、OSのタイムゾーンは Etc/UTC です。

$ cat /etc/timezone
Etc/UTC

Dockerコンテナで再現

タイムゾーンのデータ（tzdata）が入っていない小さなイメージで、設定を変えて date と Java の時刻を出しました（20:55 JST に実行）。

$ docker run --rm -e TZ=Asia/Tokyo tzdemo:1 date
Sat Oct 10 11:55:30 Asia 2026          ← tzdata が無いので Asia/Tokyo を解釈できず UTC のまま

$ docker run --rm -e TZ=Asia/Tokyo tzdemo:1 java -cp / Now
default zone  : Asia/Tokyo
LocalDateTime : 2026-10-10T20:55:30.891036748   ← Java は自前のデータを持つので正しい

ここから分かることは2つです。

• TZ 環境変数は、イメージに tzdata が入っていないと date やC言語系のプログラム（MySQL・PostgreSQL のサーバーなど）には効かない。Java は自前のタイムゾーンデータを持っているので TZ だけで効きます
• /etc/localtime のマウントだけでは Java に効かないことがある。Java は Linux で、環境変数 TZ や /etc/localtime のリンク先のファイル名からタイムゾーン名を決めます。リンクではなくファイルとしてマウントされ、比べる先の /usr/share/zoneinfo もイメージに無かったため、名前を決められず GMT になりました

直し方：Dockerfile で tzdata を入れて TZ を指定するのが確実です。

# Debian・Ubuntu 系
RUN apt-get update && apt-get install -y --no-install-recommends tzdata && rm -rf /var/lib/apt/lists/*
ENV TZ=Asia/Tokyo

# Alpine 系
RUN apk add --no-cache tzdata
ENV TZ=Asia/Tokyo

# docker compose
services:
  app:
    environment:
      TZ: Asia/Tokyo
  db:
    image: mysql:8.4
    environment:
      TZ: Asia/Tokyo

サーバー（VM）なら sudo timedatectl set-timezone Asia/Tokyo で変えられます。ただし、サーバーをUTCのまま運用し、アプリ側で表示のときだけJSTにする方針もよく採られます（後の「保存と表示の決め方」を参照）。

例2：JavaのタイムゾーンがUTC

Java の LocalDateTime.now() や new Date() は、JVMの既定のタイムゾーンの時刻を返します。同じプログラムを、TZ を変えて実行しました。

import java.time.*;

public class Now {
    public static void main(String[] args) {
        System.out.println("default zone  : " + ZoneId.systemDefault());
        System.out.println("LocalDateTime : " + LocalDateTime.now());
        System.out.println("Instant       : " + Instant.now());
        System.out.println("Tokyo         : " + ZonedDateTime.now(ZoneId.of("Asia/Tokyo")));
        System.out.println("java.util.Date: " + new java.util.Date());
    }
}

--- TZ=UTC
default zone  : UTC
LocalDateTime : 2026-10-10T11:53:01.631682415          ← 9時間遅い
Instant       : 2026-10-10T11:53:01.631842577Z         ← Instant は常にUTC（正しい）
Tokyo         : 2026-10-10T20:53:01.642927670+09:00[Asia/Tokyo]
java.util.Date: Sat Oct 10 11:53:01 UTC 2026

--- TZ=UTC で -Duser.timezone=Asia/Tokyo を付けた
default zone  : Asia/Tokyo
LocalDateTime : 2026-10-10T20:53:01.889099354          ← 正しい

直し方は3通りです。上ほど影響範囲が広くなります。

-Duser.timezone を付けられないときは、環境変数 JAVA_TOOL_OPTIONS=-Duser.timezone=Asia/Tokyo でも同じ指定ができます。Instant と OffsetDateTime・ZonedDateTime は瞬間を表すのでずれません。ずれるのは、タイムゾーンを持たない LocalDateTime と、表示のときにJVMのタイムゾーンを使う java.util.Date・java.sql.Timestamp です。

例3：MySQLのDATETIMEとTIMESTAMPで9時間ずれる

MySQL の時刻は、セッションの time_zone で決まります。既定は SYSTEM（OSのタイムゾーン）なので、OSがUTCならUTCです。

mysql> SELECT @@global.time_zone, @@system_time_zone, @@session.time_zone;
+--------------------+--------------------+---------------------+
| SYSTEM             | UTC                | SYSTEM              |
+--------------------+--------------------+---------------------+
mysql> SELECT NOW();
| 2026-10-10 11:52:47 |      ← 9時間遅い

さらに、TIMESTAMP 型はセッションのタイムゾーンで変換され、DATETIME 型は変換されません。UTCのセッションで2つの型に同じ値を入れ、セッションを +09:00 にして読み直すと、TIMESTAMP だけ9時間進みます。

CREATE TABLE t (id INT PRIMARY KEY, dt DATETIME, ts TIMESTAMP);
INSERT INTO t VALUES (1, '2026-10-10 09:00:00', '2026-10-10 09:00:00');  -- セッションはUTC
SET time_zone = '+09:00';
SELECT id, dt, ts FROM t;

+----+---------------------+---------------------+
| id | dt                  | ts                  |
+----+---------------------+---------------------+
|  1 | 2026-10-10 09:00:00 | 2026-10-10 18:00:00 |   ← TIMESTAMP だけ +9時間
+----+---------------------+---------------------+

アプリとバッチでDB接続のタイムゾーンが違う、移行の前後でサーバーの設定が違う、といったときに「片方の画面だけ9時間ずれる」が起きます。

Asia/Tokyo を指定するとエラーになる

mysql> SET time_zone = 'Asia/Tokyo';
ERROR 1298 (HY000): Unknown or incorrect time zone: 'Asia/Tokyo'

MySQL は、タイムゾーンのテーブルを読み込むまで Asia/Tokyo のような名前を使えません（'+09:00' のような時差の指定は使えます）。Linux なら次のコマンドで読み込み、MySQL を再起動します。

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql

mysql> SET time_zone = 'Asia/Tokyo';
mysql> SELECT @@session.time_zone, NOW();
| Asia/Tokyo          | 2026-10-10 20:52:54 |

直し方：サーバー全体をJSTにするなら、設定ファイルに書きます。

[mysqld]
default-time-zone = '+09:00'

日本には夏時間が無いので、'+09:00' で困ることはありません。タイムゾーンのテーブルを読み込んであれば 'Asia/Tokyo' とも書けます。Amazon RDS・Aurora はパラメータグループの time_zone で指定します。

例4：PostgreSQLのTimeZoneがUTC

PostgreSQL も、セッションの TimeZone で表示が変わります。timestamptz（timestamp with time zone）はUTCで保存され、表示のときにセッションのタイムゾーンに変換されます。

tzdemo=# SHOW TimeZone;
 Etc/UTC
tzdemo=# SELECT id, ts, tstz FROM t;
 id |         ts          |          tstz
----+---------------------+------------------------
  1 | 2026-10-10 09:00:00 | 2026-10-10 00:00:00+00   ← 日本時間 9:00 が UTC の 0:00 で表示される

tzdemo=# SET TIME ZONE 'Asia/Tokyo';
tzdemo=# SELECT id, ts, tstz FROM t;
  1 | 2026-10-10 09:00:00 | 2026-10-10 09:00:00+09

timestamp（without time zone）の列には注意が要ります。'2026-10-10 09:00:00+09' と時差付きで入れても、時差は黙って捨てられます（id=2 の行で確認しました）。

直し方：データベース単位でタイムゾーンを決めておくと、接続するすべてのクライアントに効きます。

ALTER DATABASE tzdemo SET timezone TO 'Asia/Tokyo';   -- 次の接続から有効

サーバー全体なら postgresql.conf の timezone = 'Asia/Tokyo' です。

例5：JDBCドライバで9時間ずれる（Java＋DB）

Java から DB に接続すると、JVMのタイムゾーンがDBのセッションにも影響します。PostgreSQL JDBC Driver は、接続時に JVM のタイムゾーンをセッションの TimeZone に設定します。同じプログラムを TZ だけ変えて実行しました。

try (Connection c = DriverManager.getConnection("jdbc:postgresql://localhost:5432/tzdemo", "postgres", "pass");
     Statement s = c.createStatement()) {
    ResultSet r = s.executeQuery("SHOW TimeZone"); r.next();
    System.out.println("JVM=" + ZoneId.systemDefault() + "  session TimeZone=" + r.getString(1));
    r = s.executeQuery("SELECT now()::timestamp AS local_now, ts, tstz FROM t WHERE id = 1"); r.next();
    System.out.println("now()::timestamp         : " + r.getString("local_now"));
    System.out.println("tstz getObject(OffsetDT) : " + r.getObject("tstz", OffsetDateTime.class));
    System.out.println("tstz getTimestamp        : " + r.getTimestamp("tstz"));
}

--- TZ=UTC
JVM=UTC  session TimeZone=UTC
now()::timestamp         : 2026-10-10 11:53:14.396139     ← 9時間遅い
tstz getObject(OffsetDT) : 2026-10-10T00:00Z               ← 瞬間としては正しい
tstz getTimestamp        : 2026-10-10 00:00:00.0           ← 表示は9時間遅い

--- TZ=Asia/Tokyo
JVM=Asia/Tokyo  session TimeZone=Asia/Tokyo
now()::timestamp         : 2026-10-10 20:53:14.943062
tstz getObject(OffsetDT) : 2026-10-10T00:00Z
tstz getTimestamp        : 2026-10-10 09:00:00.0

DB側でデータベースのタイムゾーンを Asia/Tokyo にしていても、Javaから接続するとJVMのタイムゾーン（UTC）で上書きされます。PostgreSQL では、JVMのタイムゾーンをそろえるのが直し方です（例2）。

MySQL Connector/J の設定

MySQL Connector/J 8.0.23 以降は、次の3つの接続プロパティで TIMESTAMP の変換を決めます。

既定の connectionTimeZone=LOCAL は「DBのセッションはJVMと同じタイムゾーン」とみなします。JVMはJST、MySQLはUTC（またはその逆）だと、この前提が崩れて9時間ずれます。 MySQL公式マニュアルが一般に安全としている書き方は次のとおりです。

jdbc:mysql://localhost:3306/app?preserveInstants=true&connectionTimeZone=SERVER

以前の版で使われていた serverTimezone は、8.0.23 から connectionTimeZone の別名になっています。Spring Boot＋Hibernate では、spring.jpa.properties.hibernate.jdbc.time_zone を指定している場合もその値で変換されるので、設定ファイルも確認します。

例6：Pythonのdatetimeで9時間ずれる

Python の datetime.now() は、OSのタイムゾーンの時刻を、タイムゾーンを持たない値（naive）で返します。

import datetime as dt
from zoneinfo import ZoneInfo
JST = ZoneInfo("Asia/Tokyo")

print(dt.datetime.now())                     # OSのタイムゾーン（naive）
print(dt.datetime.now(JST))                  # 常にJST（aware）
print(dt.datetime.fromtimestamp(1791590400)) # UNIX時刻 → OSのタイムゾーン
print(dt.datetime.fromtimestamp(1791590400, JST))

--- TZ=UTC
2026-10-10 11:53:35.381761              ← 9時間遅い
2026-10-10 20:53:35.381800+09:00
2026-10-10 00:00:00                     ← 9時間遅い
2026-10-10 09:00:00+09:00

--- TZ=Asia/Tokyo
2026-10-10 20:53:35.422178
2026-10-10 20:53:35.422212+09:00
2026-10-10 09:00:00
2026-10-10 09:00:00+09:00

datetime.utcnow() は Python 3.12 から非推奨になり、実行すると DeprecationWarning が出ます。UTCがほしいときは datetime.now(datetime.UTC) と書きます。now(JST)・fromtimestamp(..., JST) のようにタイムゾーンを渡しておけば、実行環境がUTCでもずれません。 APIの "2026-10-10T00:00:00Z" は datetime.fromisoformat()（3.11以降は Z も読める）で読み、.astimezone(JST) で日本時間にします。

例7：JavaScriptのDateで9時間・1日ずれる

JavaScript では、文字列の書き方によってUTCとして読むかローカル時刻として読むかが変わります。日本のPC（TZ=Asia/Tokyo）で実行しました。

new Date('2026-10-10').toString()
new Date('2026-10-10T00:00').toString()
new Date('2026-10-10T08:00:00+09:00').toISOString().slice(0, 10)
JSON.stringify({ d: new Date('2026-10-10T09:00:00+09:00') })

Sat Oct 10 2026 09:00:00 GMT+0900   ← 日付だけの文字列は UTC の 0:00 として読まれる
Sat Oct 10 2026 00:00:00 GMT+0900   ← 日付と時刻があればローカル時刻
2026-10-09                          ← UTC に直してから切り出したので前日になる
{"d":"2026-10-10T00:00:00.000Z"}    ← JSON は UTC の文字列になる

直し方：日付の文字列を作るときは toISOString() を使わず、タイムゾーンを指定して整形します。

const d = new Date('2026-10-09T23:30:00Z');      // 日本時間 10/10 8:30
new Intl.DateTimeFormat('sv-SE', { timeZone: 'Asia/Tokyo' }).format(d);
// → "2026-10-10"（sv-SE は yyyy-mm-dd 形式で出る）
new Intl.DateTimeFormat('sv-SE', { timeZone: 'Asia/Tokyo', dateStyle: 'short', timeStyle: 'medium' }).format(d);
// → "2026-10-10 08:30:00"

timeZone: 'Asia/Tokyo' を指定すると、利用者のPCやサーバー（Node.js）がUTCでも同じ結果になります（TZ=UTC でも同じ値を確認しました）。日付だけの入力（<input type="date"> の値など）を Date にするときは、'2026-10-10T00:00' のように時刻を付けるとローカル時刻として読まれます。

保存と表示の決め方

9時間ずれを繰り返さないためには、「DBにはどのタイムゾーンで保存するか」をチームで1つに決めておくことです。

どちらでも、次の3つを守るとずれません。

• APIのJSONは時差付き（2026-10-10T09:00:00+09:00 または ...Z）で受け渡す
• 「今日」「締め時刻」の判定は、タイムゾーンを明示して計算する（LocalDate.now(ZoneId.of("Asia/Tokyo")) など）
• バッチ・ログ収集・DBのコンテナも同じタイムゾーンにする（アプリだけ直すと、ログやバッチの時刻がずれたまま残る）

確認の手順（チェックリスト）

よくある質問

Q. 開発PCでは正しいのに、本番だけ9時間ずれます。 A. 開発PCは日本時間、本番のサーバーやコンテナはUTCという組み合わせがほとんどです。例1・2の方法で本番のOSとJVMのタイムゾーンを確認します。コードで ZoneId.of("Asia/Tokyo") を明示しておくと、実行環境に左右されません。

Q. 画面は正しいのに、CSV出力やバッチだけずれます。 A. CSV出力やバッチが、別のJVM・別のコンテナ・別のDB接続設定で動いていることが多い原因です。バッチの起動スクリプトに -Duser.timezone が無い、cron がUTCで動いている、などを確認します。

Q. MySQLのDATETIMEとTIMESTAMPはどちらを使えばよいですか。 A. 国内だけで使うシステムで全層をJSTにそろえるなら DATETIME が分かりやすく、セッションの設定の影響も受けません。TIMESTAMP は保存できる範囲が2038年1月19日（UTC）までという制約もあります。複数のタイムゾーンを扱うなら、UTCで保存すると決めて DATETIME に入れる方法もあります。

Q. 夏時間（サマータイム）は気にする必要がありますか。 A. 日本には夏時間が無いので、日本時間だけを扱うなら +09:00 固定で問題ありません。海外拠点の時刻を扱う場合は、America/New_York のような地域名で指定すると夏時間も自動で切り替わります。

まとめ

• 9時間ずれは、UTCとJSTがどこかで入れ替わっている。ずれの向き（遅い・進む・前日）で原因を絞る
• コンテナは既定でUTC。TZ は tzdata が無いと date やDBサーバーに効かない。Java は TZ だけで効く
• Javaは -Duser.timezone=Asia/Tokyo か、コードで ZoneId.of("Asia/Tokyo") を明示する
• MySQLの TIMESTAMP はセッションのタイムゾーンで変換される。Asia/Tokyo を使うにはタイムゾーンのテーブルの読み込みが要る
• PostgreSQL JDBCはJVMのタイムゾーンをセッションに設定する。Connector/J は connectionTimeZone で決まる
• JavaScriptは '2026-10-10' をUTCとして読む。日付の文字列は Intl.DateTimeFormat に timeZone を渡して作る

参考・出典

確認日はいずれも 2026年10月10日です。

• MySQL 8.0 Reference Manual「MySQL Server Time Zone Support」：https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html
• MySQL Connector/J Developer Guide「Preserving Time Instants」：https://dev.mysql.com/doc/connector-j/en/connector-j-time-instants.html
• PostgreSQL 16 文書「Date/Time Types」：https://www.postgresql.org/docs/16/datatype-datetime.html
• MDN Web Docs「Date.parse()」：https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse
• MySQL Connector/J 9.7.0 ソース（接続プロパティの説明と既定値）：https://github.com/mysql/mysql-connector-j

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。