Skip to main content

MY.L6.TIME_ZONE_NOT_UTC — a server whose clock is the host's, not a decision

  • Category: idiom
  • Level: 6
  • Confidence: deterministic
  • Downtime class: none
  • Stability: stable
  • Suites: audit
  • Applies to: MySQL 8.4
  • Not transferable to MariaDB: this page describes MySQL 8.4 behavior. MariaDB answers the same driver and does not share these semantics, so SQLens refuses it outright rather than reasoning about it — see drivers/unsupported.

MySQL ships with time_zone = SYSTEM, which means whatever the host's clock is set to. The database's behavior is then a property of the machine it happens to run on.

Measured on a real MySQL 8.4 running SYSTEM:

SELECT CONVERT_TZ('2026-01-01 14:00:00', 'SYSTEM', '+00:00');
-- 2026-01-01 13:00:00

The server silently used the host's offset. Nothing raised, nothing warned, and the answer is only correct if the host is configured the way whoever wrote the query assumed. Move the server to a differently-configured machine, or re-image the one it is on, and the same schema converts differently — with nothing in the database changed.

Why SYSTEM is worse than a wrong zone​

The other values at least name a zone, so two servers configured alike behave alike. SYSTEM names nothing. It is not a setting so much as a deferral, and what it defers to is outside the database entirely.

Prefer the offset form​

+00:00 works on every MySQL. The named spellings — UTC, Etc/UTC — need the timezone tables loaded into the mysql schema, and a fresh install has none.

On the same server, with mysql.time_zone_name empty:

SELECT CONVERT_TZ('2026-01-01 14:00:00', 'UTC', '+00:00');
-- NULL

A rule that demanded the named spelling would push projects toward a configuration that silently produces NULL on their server. So all three spellings are accepted.

Flagged​

SET GLOBAL time_zone = 'SYSTEM';

Preferred​

SET GLOBAL time_zone = '+00:00';

What is not accepted​

GMT, Etc/GMT, Universal and Zulu resolve to the same instant and are deliberately not accepted — the same argument the PostgreSQL rule makes. They are the same offset but a different statement of intent, and the next person to touch a server set to GMT may well "correct" it to a local zone.

What is read, and what is not​

Only the server's value. Laravel sets the session timezone from the connection config on every connection it opens, so a session running something else is the framework's choice and not a statement about the server.

A value the server withholds is reported as undetermined with a reason, never as a pass.

Sources​