> 404 motivation not found
Prisma MySQL でUTC以外の任意のタイムゾーンを利用するのが難しい件

Prisma MySQL でUTC以外の任意のタイムゾーンを利用するのが難しい件

2022-08-0819 min read

目次

  1. 概要
  2. 検証方法
  3. 結果
  4. 結果-1
  5. 余談
  6. 参考にしたサイト

概要

タイトルにもあるように、 Prisma+MySQL の構成で任意のタイムゾーンを DB で利用するのが難しいです。 素直に UTC を使うべきという感想になりました。

検証してみたので、結果を記載したいと思います。

検証方法

  • アプリケーションの実行環境は JST・UTC
  • DB の実行環境は JST・UTC

上記の 2 つの組み合わせパターンで検証を行います。

また後述しますが、アプリケーション側で生成したシステム時間と DB で生成したシステム時間をそれぞれ登録します。

登録した値を取り出し、JST に変更することで合っているかどうかを確認します。

検証した環境

  • Prisma: 4.1.1

検証するコード

import { Prisma, PrismaClient } from '@prisma/client';

// process.env.TZ = "UTC";
process.env.TZ = 'Asia/Tokyo';

const prisma = new PrismaClient();

async function main() {
  await prisma.user.deleteMany();
  await prisma.user.create({
    data: {
      userInputDate1: new Date(),
    },
  });
  const allUsers = await prisma.user.findMany();
  for (let i in allUsers) {
    const row = allUsers[i];
    let obj = {
      userInputDate1: row.userInputDate1?.toLocaleString(),
      createdAt1: row.createdAt1.toLocaleString(),
      createdAt2: row.createdAt2.toLocaleString(),
      createdAt3: row.createdAt3.toLocaleString(),
      createdAt4: row.createdAt4.toLocaleString(),
      createdAt5: row.createdAt5.toLocaleString(),
    };
    console.log(row);
    console.log(obj);
  }
}

main()
  .catch((e) => {
    throw e;
  })
  .finally(async () => {
    await prisma.$disconnect();
  });

スキーマは次のように設定しておきます。

model User {
  id Int @id @default(autoincrement())
  userInputDate1 DateTime?
  createdAt1 DateTime @default(now()) @db.Timestamp(0)
  createdAt2 DateTime @default(dbgenerated("NOW()")) @db.Timestamp(0)
  createdAt3 DateTime @default(now())
  createdAt4 DateTime @default(now()) @db.DateTime(0)
  createdAt5 DateTime @default(dbgenerated("NOW()")) @db.DateTime(0)
}

dbgeneratedは DB の組み込み関数を呼び出す機能です。 これを使って MySQL のNOW()を呼び出します。

生成された型は次のようになります。

+----------------+-------------+------+-----+----------------------+-------------------+
| Field          | Type        | Null | Key | Default              | Extra             |
+----------------+-------------+------+-----+----------------------+-------------------+
| id             | int         | NO   | PRI | NULL                 | auto_increment    |
| userInputDate1 | datetime(3) | YES  |     | NULL                 |                   |
| createdAt1     | timestamp   | NO   |     | CURRENT_TIMESTAMP    | DEFAULT_GENERATED |
| createdAt2     | timestamp   | NO   |     | CURRENT_TIMESTAMP    | DEFAULT_GENERATED |
| createdAt3     | datetime(3) | NO   |     | CURRENT_TIMESTAMP(3) | DEFAULT_GENERATED |
| createdAt4     | datetime    | NO   |     | CURRENT_TIMESTAMP    | DEFAULT_GENERATED |
| createdAt5     | datetime    | NO   |     | CURRENT_TIMESTAMP    | DEFAULT_GENERATED |
+----------------+-------------+------+-----+----------------------+-------------------+

結果

それぞれの比較結果を記載していきます。

アプリ=JST,DB=JST

アプリ・DB がそれぞれ JST の場合、次のようになりました。

"2022-08-07T06:18:51.774Z" // JST 2022/8/7 15:18
// DBに登録されていた値
{
  "userInputDate1": "2022-08-07T06:18:51.761Z",
  "createdAt1": "2022-08-07T06:18:52.000Z",
  "createdAt2": "2022-08-07T15:18:51.000Z",
  "createdAt3": "2022-08-07T06:18:51.763Z",
  "createdAt4": "2022-08-07T06:18:52.000Z",
  "createdAt5": "2022-08-07T15:18:51.000Z"
}
// JSTに変換した値
{
  "userInputDate1": "2022/8/7 15:18:51",
  "createdAt1": "2022/8/7 15:18:52",
  "createdAt2": "2022/8/8 0:18:51",
  "createdAt3": "2022/8/7 15:18:51",
  "createdAt4": "2022/8/7 15:18:52",
  "createdAt5": "2022/8/8 0:18:51"
}

createdAt2 および createdAt5 で JST 基準で+9 時間ずれが発生しています。

一方で MySQL を直接参照しにいくと、、、

mysql> show variables like '%time_zone%';
+------------------+------------+
| Variable_name    | Value      |
+------------------+------------+
| system_time_zone | JST        |
| time_zone        | Asia/Tokyo |
+------------------+------------+
2 rows in set (0.00 sec)

mysql> select * from User\G
*************************** 1. row ***************************
            id: 7
userInputDate1: 2022-08-07 06:18:51.761
    createdAt1: 2022-08-07 06:18:52
    createdAt2: 2022-08-07 15:18:51
    createdAt3: 2022-08-07 06:18:51.763
    createdAt4: 2022-08-07 06:18:52
    createdAt5: 2022-08-07 15:18:51
1 row in set (0.00 sec)

createdAt2 createdAt5 以外で JST 基準で-9 時間のズレが発生していました。

アプリ=UTC,DB=JST

アプリ・DB がそれぞれ UTC・JST の場合、次のようになりました。

"2022-08-07T06:34:40.209Z" // JST 2022/8/7 15:34
{
  "userInputDate1": "2022-08-07T06:34:40.193Z",
  "createdAt1": "2022-08-07T06:34:40.000Z",
  "createdAt2": "2022-08-07T15:34:40.000Z",
  "createdAt3": "2022-08-07T06:34:40.195Z",
  "createdAt4": "2022-08-07T06:34:40.000Z",
  "createdAt5": "2022-08-07T15:34:40.000Z"
}
{
  "userInputDate1": "2022/8/7 6:34:40",
  "createdAt1": "2022/8/7 6:34:40",
  "createdAt2": "2022/8/7 15:34:40",
  "createdAt3": "2022/8/7 6:34:40",
  "createdAt4": "2022/8/7 6:34:40",
  "createdAt5": "2022/8/7 15:34:40"
}

reatedAt2 createdAt5 について以外で UTC 基準で+9 時間のずれが発生していました。

※Date#toLocaleStringはアプリケーションのタイムゾーンに合わせて計算するため、このケースの場合は UTC 時間が出力される。

mysql> show variables like '%time_zone%';
+------------------+------------+
| Variable_name    | Value      |
+------------------+------------+
| system_time_zone | JST        |
| time_zone        | Asia/Tokyo |
+------------------+------------+
2 rows in set (0.00 sec)

mysql> select * from User\G;
*************************** 1. row ***************************
            id: 8
userInputDate1: 2022-08-07 06:34:40.193
    createdAt1: 2022-08-07 06:34:40
    createdAt2: 2022-08-07 15:34:40
    createdAt3: 2022-08-07 06:34:40.195
    createdAt4: 2022-08-07 06:34:40
    createdAt5: 2022-08-07 15:34:40
1 row in set (0.00 sec)

DB も同様に、createdAt2 createdAt5 以外で JST 基準で-9 時間のずれが発生していました。

アプリ=JST,DB=UTC

アプリ・DB がそれぞれ JST・UTC の場合、次のようになりました。

"2022-08-07T06:49:20.806Z" // JST 2022/8/7 15:49
{
  "id": 2,
  "userInputDate1": "2022-08-07T06:49:20.795Z",
  "createdAt1": "2022-08-07T06:49:21.000Z",
  "createdAt2": "2022-08-07T06:49:20.000Z",
  "createdAt3": "2022-08-07T06:49:20.797Z",
  "createdAt4": "2022-08-07T06:49:21.000Z",
  "createdAt5": "2022-08-07T06:49:20.000Z"
}
{
  "userInputDate1": "2022/8/7 15:49:20",
  "createdAt1": "2022/8/7 15:49:21",
  "createdAt2": "2022/8/7 15:49:20",
  "createdAt3": "2022/8/7 15:49:20",
  "createdAt4": "2022/8/7 15:49:21",
  "createdAt5": "2022/8/7 15:49:20"
}

全ての値が JST 基準でズレが発生していませんでした。

ぱっと見問題なさそうに見えますが、DB では違った結果となりました。

mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | UTC    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.01 sec)

mysql> select * from User\G
*************************** 1. row ***************************
            id: 2
userInputDate1: 2022-08-07 06:49:20.795
    createdAt1: 2022-08-07 06:49:21
    createdAt2: 2022-08-07 06:49:20
    createdAt3: 2022-08-07 06:49:20.797
    createdAt4: 2022-08-07 06:49:21
    createdAt5: 2022-08-07 06:49:20
1 row in set (0.01 sec)

mysql> set time_zone='Asia/Tokyo';
Query OK, 0 rows affected (0.00 sec)

mysql> select * from User\G
*************************** 1. row ***************************
            id: 2
userInputDate1: 2022-08-07 06:49:20.795
    createdAt1: 2022-08-07 15:49:21
    createdAt2: 2022-08-07 15:49:20
    createdAt3: 2022-08-07 06:49:20.797
    createdAt4: 2022-08-07 06:49:21
    createdAt5: 2022-08-07 06:49:20
1 row in set (0.01 sec)

mysql>

DB は、createdAt1, createdAt2 (Timestamp 型)のもの以外は、JST で表示した場合、 -9 時間のズレが発生しました。

アプリ=UTC,DB=UTC

アプリおよび DB が UTC のケースです。

"2022-08-07T07:00:05.604Z" // JST 2022/8/7 16:00
{
  "id": 3,
  "userInputDate1": "2022-08-07T07:00:05.592Z",
  "createdAt1": "2022-08-07T07:00:06.000Z",
  "createdAt2": "2022-08-07T07:00:05.000Z",
  "createdAt3": "2022-08-07T07:00:05.594Z",
  "createdAt4": "2022-08-07T07:00:06.000Z",
  "createdAt5": "2022-08-07T07:00:05.000Z"
}
{
  "userInputDate1": "2022/8/7 7:00:05",
  "createdAt1": "2022/8/7 7:00:06",
  "createdAt2": "2022/8/7 7:00:05",
  "createdAt3": "2022/8/7 7:00:05",
  "createdAt4": "2022/8/7 7:00:06",
  "createdAt5": "2022/8/7 7:00:05"
}

出力自体は UTC 基準では問題ないように見えます。

mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | UTC    |
| time_zone        | SYSTEM |
+------------------+--------+
2 rows in set (0.01 sec)

mysql> select * from User\G
*************************** 1. row ***************************
            id: 3
userInputDate1: 2022-08-07 07:00:05.592
    createdAt1: 2022-08-07 07:00:06
    createdAt2: 2022-08-07 07:00:05
    createdAt3: 2022-08-07 07:00:05.594
    createdAt4: 2022-08-07 07:00:06
    createdAt5: 2022-08-07 07:00:05
1 row in set (0.00 sec)

mysql> set time_zone='Asia/Tokyo';
Query OK, 0 rows affected (0.00 sec)

mysql> select * from User\G
*************************** 1. row ***************************
            id: 3
userInputDate1: 2022-08-07 07:00:05.592
    createdAt1: 2022-08-07 16:00:06
    createdAt2: 2022-08-07 16:00:05
    createdAt3: 2022-08-07 07:00:05.594
    createdAt4: 2022-08-07 07:00:06
    createdAt5: 2022-08-07 07:00:05
1 row in set (0.00 sec)

DB は、createdAt1, createdAt2 (Timestamp 型)のもの以外は、JST で表示した場合、 -9 時間のズレが発生しました。

結果

アプリケーション x DB = JSTxJST UTCxJST JSTxUTC UTCxUTC
1 Prisma 生成 Timestamp 型 ○ ○
2 DB 生成 Timestamp 型 ○ ○ ○
3 Prisma 生成 DateTime(3)型
4 Prisma 生成 DateTime 型
5 DB 生成 DateTime 型

○ = DB とアプリケーションの両環境で JST と UTC の両パターンの表示で問題ないことを確認

この結果から JST が必要な場合でも

  • DB は UTC で構築する
  • 型に Timestamp 型を利用する
    • ただし、Timestamp型自体は2038年問題を抱えており、対策を別途検討しなければならない

という苦しい条件での構築になると思いました。

余談

余談ですが、Prisma 側でコネクション作成時に set time_zone='Asia/Tokyo';を試しましたが上手くいかなかったです。

バージョンアップでオプションが付いてくれると嬉しいですね。

参考にしたサイト

Recommends
Prisma MySQL でUTC以外の任意のタイムゾーンを利用するのが難しい件
2022-08-08
prismatypescriptmysql
Prisma TypeScript MySQLなプロジェクトの構築
2022-08-08
prismatypescriptmysql
PrismaでN対N(多対多)のテーブルを作成するときのTips
2023-04-30
node.jsjavascripttypescript
Prisma頻出コマンドとマイグレーションの運用
2023-06-28
prismatypescriptnode.js
NestJS + Prisma で Stream を用いた file download
2023-03-19
nestjsprismanode.js
Prisma で Iterator を作成する
2023-03-19
prismanode.jstypescript
zod-prisma-types で Prisma から Zod を生成する
2023-03-13
prismanode.jstypescript
NestJS Prisma Zod OpenAPI で型を堅牢にする
2023-03-13
nestjsprismanode.js
DistrolessコンテナでPrismaを動かす
2023-01-14
prismajavascripttypescript
NestJS+Prismaのバンドルツール比較とコンテナイメージ軽量化
2023-01-22
webpacknestjsprisma
Turborepoを利用したmonorepo構成のNestJS+Prismaプロジェクトの...
2023-01-04
turboreponestjsprisma
Prisma TypeScript SQLiteなプロジェクトの構築
2022-08-06
prismatypescriptsqlite
AWS CDK v2 でVPC上にAPI Gateway + Lambda + RDS +...
2022-02-28
amazon%20awsaws%20cdknode.js
NestJSでBasic認証
2023-07-08
nestjstypescriptnode.js
Node.js TypeScript で OpenAI
2023-03-26
node.jsjavascripttypescript
New Posts
NestJSでBasic認証
2023-07-08
nestjstypescriptnode.js
Prisma頻出コマンドとマイグレーションの運用
2023-06-28
prismatypescriptnode.js
ChatGPT API でレスポンスをJSONとして受け取る
2023-06-18
chatgptopenainode.js
PrismaでN対N(多対多)のテーブルを作成するときのTips
2023-04-30
node.jsjavascripttypescript
Node.js TypeScript で OpenAI
2023-03-26
node.jsjavascripttypescript
NestJS + Prisma で Stream を用いた file download
2023-03-19
nestjsprismanode.js
Prisma で Iterator を作成する
2023-03-19
prismanode.jstypescript
zod-prisma-types で Prisma から Zod を生成する
2023-03-13
prismanode.jstypescript
NestJS Prisma Zod OpenAPI で型を堅牢にする
2023-03-13
nestjsprismanode.js
Headless CMS の Strapi をインストールからAPIエンドポイント作成
2023-03-12
strapijavascriptnode.js
React/Next.jsでcanvasを利用する
2023-02-26
reactnext.jstypescript
[turborepo]monorepo管理のNext.jsアプリをvercelにデプロイ
2023-02-23
vercelturboreponext.js
JSのDateに渡せる文字列のパターンが複雑なので網羅してみる
2024-05-25
javascripttypescriptnode.js
[Unicode]スペース以外の見えない空白文字の一覧
2023-02-18
javascript
VSCode+zshで _arguments:comparguments:409: not...
2023-01-29
linuxvscodemac
Hot posts!
Proxy環境下でcurlを実行する
2019-12-07
linuxcurl
OpenCVのMatのタイプ一覧表
2018-11-25
%E7%94%BB%E5%83%8F%E5%87%A6%E7%90%86opencv
Macでも利用できるDBクライアント MySQL PostgreSQL Oracle など
2019-12-21
linux%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9mysql
TablePlusを使ってみる。シンプルでモダンなSQLクライアントツール
2018-09-30
%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9
DBクライアントツールはDBeaverをおすすめしたい
2021-03-08
oraclemysqlsqlite
AWS S3のアクセスキーIDとシークレットアクセスキーの取得 作業用ユーザを作成
2019-06-12
amazon%20awslinuxamazon%20s3
AtCoderで初めて色がつくまでの話(茶色) レートが中々上がらなかった原因
2018-11-25
%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0%E7%AB%B6%E6%8A%80%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E9%9B%91%E8%AB%87
CentOS8でEPELとPowerToolsリポジトリの有効化
2020-11-30
centosred%20hatEPEL
Macでターミナルからポートスキャンを行う方法。
2018-12-09
linuxmacapple
Python + OpenCVのfillConvexPolyで複雑なポリゴンを描画する
2018-11-27
python%E7%94%BB%E5%83%8F%E5%87%A6%E7%90%86opencv
Author
githubzennqiita
ただの備忘録です。

※外部送信に関する公表事項