この記事の要点
MariaDB / MySQL の現在日時取得関数 日付: CURRENT_DATE（または CURDATE()） 時刻: CURRENT_TIME（または CURTIME()） 日時: CURRENT_TIMESTAMP（または NOW()）— カラム DEFAULT 値にも使える

 

MariaDBの現在日時を取得する関数です。以下の2017年の出力は当時の例として残しています。返る日付・時刻は実行時点と接続のタイムゾーンで変わり、毎回同じ値になるものではありません。後半ではMariaDB 11.4系とMySQL 8.0で確認した実行例を追加します。

現在日時を取得する構文

    //現在日付の取得関数
    CURRENT_DATE

    //現在時刻の取得関数
    CURRENT_TIME

    //現在日時の取得関数
    CURRENT_TIMESTAMP

 

元の実行例

    > SELECT CURRENT_DATE;
    +--------------+
    | CURRENT_DATE |
    +--------------+
    | 2017-07-07   |
    +--------------+
    1 row in set (0.01 sec)
    

    > SELECT CURRENT_TIME;
    +--------------+
    | CURRENT_TIME |
    +--------------+
    | 05:56:18     |
    +--------------+
    1 row in set (0.00 sec)

    > SELECT CURRENT_TIMESTAMP;
    +---------------------+
    | CURRENT_TIMESTAMP   |
    +---------------------+
    | 2017-07-07 05:56:18 |
    +---------------------+
    1 row in set (0.00 sec)

 

日付・時刻・日時の使い分け

必要な値	関数	注意
日付	CURRENT_DATE / CURDATE()	時刻を含まない
時刻	CURRENT_TIME / CURTIME()	日付を含まない
日時	CURRENT_TIMESTAMP / NOW()	セッションのタイムゾーンで返る
UTCの日時	UTC_TIMESTAMP()	表示・保存先の変換規則も確認
小数秒付き日時	NOW(6)	小数秒6桁。保存先にも対応する精度が必要

CURRENT_TIMESTAMPは現在日時を返す関数名です。TIMESTAMPというカラム型を使わなければ呼べない、という意味ではありません。同じSQL文のNOW()等は文の開始時点を基準にするため、処理途中で待機しても呼出しごとに時計が進むとは限りません。

値が9時間ずれるときの確認

まず実際に使うアプリのDB接続で以下を確認します。別クライアントの確認だけでは、アプリ接続にも同じ設定が使われているとは限りません。すべてSELECTで、データや設定を変更しません。

SELECT VERSION() AS db_version,
       @@session.time_zone AS session_time_zone,
       @@global.time_zone AS global_time_zone,
       @@system_time_zone AS system_time_zone;

SELECT CURRENT_DATE AS current_date_value,
       CURRENT_TIME AS current_time_value,
       CURRENT_TIMESTAMP AS current_timestamp_value,
       NOW(6) AS current_timestamp_microseconds,
       UTC_TIMESTAMP() AS utc_timestamp_value;

@@session.time_zoneはこの接続の設定です。SYSTEMならシステムのタイムゾーンに依存します。アプリやOSの時計・タイムゾーン設定とDB接続の設定を混同しないでください。今回の検証ではセッション+00:00から+09:00へ変えるとNOW()が9時間進み、UTC_TIMESTAMP()は同じUTC時刻でした。

TIMESTAMPとDATETIMEの違いを検証する

以下は隔離した学習用DB専用です。 新規テーブルを作り1行挿入するので、読み取り確認SQLとは別です。本番や既存テーブルで実行せず、example_clockという名前が未使用の使い捨てDBで確認します。SET SESSIONはこの接続だけを変え、アプリの別接続やサーバー全体の設定を変えるものではありません。

SET SESSION time_zone = '+00:00';

CREATE TABLE example_clock (
    id INT PRIMARY KEY,
    created_ts TIMESTAMP(6) DEFAULT CURRENT_TIMESTAMP(6),
    created_dt DATETIME(6) DEFAULT CURRENT_TIMESTAMP(6)
);

INSERT INTO example_clock (id) VALUES (1);
SELECT id, created_ts, created_dt FROM example_clock ORDER BY id;

SET SESSION time_zone = '+09:00';
SELECT id, created_ts, created_dt FROM example_clock ORDER BY id;

最初のSELECTはUTCで、次は+09:00で同じ行を読みます。TIMESTAMPは保存/取得時のセッション換算があり、表示が9時間変わりました。DATETIMEは入力された日時の値を保持し、この切替では表示が変わりませんでした。DATETIMEにどのタイムゾーンの値を入れるかはアプリ側で設計します。

確認した結果の例

テストでは時刻を固定して比較しました。以下の2026-01-01は再現用の値で、通常実行時の現在日時ではありません。

読取セッション	created_ts	created_dt
+00:00	2026-01-01 00:00:00.000000	2026-01-01 00:00:00.000000
+09:00	2026-01-01 09:00:00.000000	2026-01-01 00:00:00.000000

DEFAULTと更新日時の注意

上の例はDEFAULT CURRENT_TIMESTAMP(6)を明示し、INSERTで日時カラムを省略して値を入れています。明示的に別の日時やNULLを渡す場合とは区別してください。DEFAULTは新規行の既定値で、更新のたびに自動で現在時刻になる設定ではありません。ON UPDATEの要否は別に設計し、SHOW CREATE TABLEで実定義を確認します。

旧版・サーバー設定によってTIMESTAMPの暗黙の既定値が違う場合があるため、省略時の自動動作に依存せず、型・DEFAULT・NULL・ON UPDATEを確認してください。日時の値域やタイムゾーン名の利用にも製品・版・設定の差があります。Asia/Tokyoなどの名前を使う場合はタイムゾーン情報の導入状況も確認します。

アプリへ組み込む前の確認

• 日時の基準をUTCか業務タイムゾーンか決め、DB接続・保存型・表示側で統一する。
• 日付境界と小数秒、保存後の再取得を確認する。現在日時の文字列だけを見て型やタイムゾーンを断定しない。
• DB側で生成した時刻とアプリ側で生成した時刻を混ぜる場合は、時計・タイムゾーンの違いを確認する。
• 設定変更後は新規接続や接続プールも含めて有効値を確認する。別クライアントでのSETだけではアプリは直らない。

今回はMariaDB 11.4.13 / MySQL 8.0.46の隔離したローカルDBで、掲載SELECT、UTC/+09の違い、同一文のNOW(6)の安定性、DEFAULTによる挿入、TIMESTAMP/DATETIMEの再取得を確認しました。本番DBの設定・スキーマ・業務データは変更していません。旧MariaDB全版や実アプリ全体の動作保証ではありません。

公式資料: MariaDB NOW、MariaDB TIMESTAMP、MariaDB DATETIME、MySQL 8.0の日時関数、MySQLの日時型（2026年10月確認）。