MySQL and the server show different times when one of three timezone layers disagrees: the operating system running mysqld, MySQL’s global default, or the timezone assigned to your current connection. Compare those layers first, then set the host, server default, and client session to an intentional policy—usually UTC for storage and a named regional zone only when displaying local civil time.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Why MySQL and the server show different times
MySQL keeps separate timezone settings. At startup, it reads the host’s timezone into @@system_time_zone. The global MySQL setting, @@GLOBAL.time_zone, normally starts as SYSTEM, meaning MySQL follows the host setting. Each new connection receives a session timezone from that global value, and @@SESSION.time_zone controls what that connection sees and how zone-sensitive values are handled.
As an Amazon Associate I earn from qualifying purchases.
| Layer | How to inspect it | What it controls | Typical failure |
|---|---|---|---|
| Operating system | Your platform’s clock and timezone tools | The clock and timezone detected by the mysqld process |
The host is on UTC while you expect local time, or its timezone database is stale |
| MySQL system | @@system_time_zone |
The timezone MySQL detected when it started | The OS timezone was changed without restarting MySQL |
| MySQL global | @@GLOBAL.time_zone |
The default assigned to new client sessions | It remains SYSTEM or is set to a different offset or named zone |
| Connection session | @@SESSION.time_zone |
Functions and zone-sensitive values for one connection | A pool or application leaves a session in the wrong zone |
The layers can legitimately differ. For example, a host may use UTC, the global default may be UTC, and a reporting connection may deliberately use Europe/Helsinki. The problem is an accidental difference, not the mere existence of multiple settings.
Diagnose the mismatch before changing anything
1. Check the host clock and timezone
On the database host, verify both the current clock and the configured timezone with the operating system’s time tools. On Linux systems, administrators commonly use date and timedatectl; use the equivalent tools for your operating system, virtual machine, container, or managed database service. Record the result, including whether the host is configured for UTC or a regional zone.
#1 Best Overall
2. Inspect all three MySQL layers
SELECT @@system_time_zone, @@GLOBAL.time_zone, @@SESSION.time_zone;
SELECT NOW(), UTC_TIMESTAMP(), CURRENT_TIMESTAMP();NOW() and CURRENT_TIMESTAMP() use the current session timezone. UTC_TIMESTAMP() always returns UTC. If the first pair is correct relative to UTC but not your expected local time, the session is probably using UTC by design. If the host’s zone and @@system_time_zone disagree, MySQL was started before the host timezone changed or the process received a different environment.
3. Test the connection that actually runs the application
Run the queries through the same driver, account, pool, and endpoint used by the application. An administrator’s interactive session can have a different @@SESSION.time_zone from a web worker or job queue. Check after a connection is created and again after a connection is returned from a pool; session settings persist until that connection is closed or explicitly changed.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Choose a timezone policy
Decide what an instant means in your system before selecting a setting. A reliable policy separates storage and calculations from presentation.
| Policy | Use it when | Representation | Operational cost |
|---|---|---|---|
| UTC everywhere | Services, logs, APIs, and data are distributed across regions | UTC as the server and session timezone |
Users need conversion at the presentation edge |
| Named regional zone | A connection must display local civil time, including daylight-saving changes | For example, Europe/Helsinki |
MySQL timezone tables must be loaded and kept current when rules change |
| Numeric offset | A fixed offset is explicitly required and daylight-saving transitions do not apply | For example, +02:00 |
The offset does not express a region’s future or historical rule changes |
For portable calculations, normalize instants to UTC, perform arithmetic there, and convert to a user’s named zone only for display. Do not infer a source timezone for old data simply from the server’s current setting; establish which timezone the application used when those rows were written.
Fix the host and MySQL startup environment
Set the environment used by mysqld
If NOW() and UNIX_TIMESTAMP() are wrong because the process is using the wrong host timezone, configure the environment before starting MySQL. MySQL documents the TZ environment variable and the --timezone and --default-time-zone server options.
TZ=UTC mysqld
mysqld --default-time-zone='UTC'Use the startup method appropriate to your installation—service manager, container entrypoint, or managed-service parameter—rather than typing a command that disappears on the next restart. Keep the intended policy in deployment configuration so replacement hosts receive the same setting.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsRestart after an operating-system timezone change
MySQL initializes @@system_time_zone at startup. If you replace the host’s timezone file or change its configured zone, restart mysqld so it reloads the rules. Apply the same step to containers and virtual machines: changing the host or image configuration does not retroactively alter a running database process.
Set MySQL’s global default and each session
Change the running server default
SET GLOBAL time_zone = 'UTC';This changes the default for new connections. Existing connections retain their current session value, so reconnect application workers or set their sessions explicitly.
Set the current connection
SET time_zone = 'UTC';
-- Or, for a regional presentation session:
SET time_zone = 'Europe/Helsinki';
-- A fixed offset is also possible:
SET time_zone = '+02:00';Use a named zone when local civil time must follow daylight-saving and other regional rule changes. Use a numeric offset only when a fixed offset is genuinely the requirement. A session setting affects the connection that executes it; it does not alter other users.
Make the default survive restarts
A runtime SET GLOBAL change is not a deployment policy by itself. Configure the server’s default timezone through the startup configuration or managed-service setting used by your installation, then restart or perform the provider’s documented apply operation. Verify the value after a restart and after a failover, not just on the primary instance.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Load named timezone data when MySQL rejects a region
A statement such as SET time_zone = 'Europe/Helsinki'; requires populated MySQL timezone tables. If the tables are missing or incomplete, MySQL returns:
ERROR 1298 (HY000): Unknown or incorrect time zoneLoad the operating system’s zoneinfo data
On systems with a zoneinfo database, load it with mysql_tzinfo_to_sql, directing the generated SQL into the MySQL client connected to the target server. Follow your platform’s package and privilege requirements; some platforms without a usable zoneinfo database provide a vendor timezone package instead.
Rank #4
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysqlThe path shown is the conventional Linux location; confirm the zoneinfo path on your system. Restart mysqld after loading data when required by your deployment, then test the named zone again. Keep the tables maintained when timezone authorities publish rule changes, because a named zone is only as accurate as the rules stored in those tables.
Understand TIMESTAMP versus DATETIME
| Type | Storage and retrieval behavior | Timezone consequence |
|---|---|---|
TIMESTAMP |
Converted from the session timezone to UTC for storage, then from UTC to the session timezone on retrieval | The same instant can display differently in two sessions |
DATETIME |
Stores the date and clock fields without automatic UTC conversion | It is timezone-naive; the fields do not identify an instant by themselves |
DATE or TIME |
Stores calendar or clock fields without automatic timezone conversion | Interpretation comes from the application and business context |
For an event that represents one instant—such as a payment, log entry, or message delivery—store and calculate against a clearly defined UTC policy. A TIMESTAMP can provide MySQL’s session-aware conversion, while a DATETIME requires the application to preserve the timezone meaning separately. Neither choice repairs ambiguous legacy rows automatically.
Do not mass-convert legacy DATETIME values blindly
Before changing existing values, determine the timezone used by the writer at the time each row was created. A value such as 2025-10-15 09:00:00 could mean UTC, a regional civil time, or merely a wall-clock appointment. If the source zone is unknown, preserve the original data and investigate application, host, and deployment history rather than guessing.
Keep replication and multiple servers aligned
MySQL’s default assumption is that source and replica servers are in the same timezone. When hosts are in different zones, leaving time_zone as SYSTEM can make the same statement evaluate differently. MySQL specifically warns that statements using NOW() or FROM_UNIXTIME() may then produce unexpected results on a replica.
Best Value
Use a deliberate configuration on every member
- Choose one documented policy, normally UTC, for source, replicas, failover targets, and maintenance tools.
- Set the global default consistently instead of relying on each host’s local
SYSTEMvalue. - Set sessions explicitly for jobs that intentionally render regional civil time.
- After a failover or rebuild, run the diagnostic queries on the new primary and replicas.
Aligning settings removes one source of divergence; it does not make a timezone-naive DATETIME an unambiguous instant. Review the data model and the statements that write time values as well.
Application and connection-pool practices
Initialize every connection
Have the application execute SET time_zone = 'UTC' (or the required named zone) immediately after opening a connection. This is safer than assuming the server global default, especially when multiple applications share a database or when a pool reuses connections.
Prevent session leakage
If one request changes a pooled connection to a regional zone, the next request can inherit it. Either prohibit per-request changes, reset the session before returning it to the pool, or set the desired timezone at checkout every time. Log the session timezone with timestamps when diagnosing an intermittent discrepancy.
Convert only at the presentation boundary
Keep API payloads, cross-region events, and internal calculations in UTC unless a business rule explicitly requires another representation. Convert to a named user or venue timezone when formatting a screen, report, or notification, and retain the zone identifier when a future rule change could affect interpretation.
Common symptoms and targeted fixes
| Symptom | Likely cause | Action |
|---|---|---|
NOW() is UTC but the team expects local time |
The session or global default is UTC | Confirm all three variables, then set the session or global policy intentionally |
@@system_time_zone is old after a host change |
mysqld has not restarted |
Restart MySQL and verify the startup environment |
| Named zone produces error 1298 | Timezone tables are not populated | Load zoneinfo data with mysql_tzinfo_to_sql or the platform package |
Two clients display one TIMESTAMP differently |
Their session timezones differ | Inspect @@SESSION.time_zone and initialize both connections consistently |
| Replica timestamps differ from source results | Hosts resolve SYSTEM to different zones |
Use compatible explicit settings and review statements containing NOW() or FROM_UNIXTIME() |
Old DATETIME records shift after conversion |
The original writer’s timezone was assumed incorrectly | Identify the historical source zone before converting; do not guess |
Verification checklist
- Record the operating-system clock and timezone on every database host.
- Run
SELECT @@system_time_zone, @@GLOBAL.time_zone, @@SESSION.time_zone;on the primary, replicas, and an application connection. - Compare
NOW(),UTC_TIMESTAMP(), andCURRENT_TIMESTAMP(). - Choose UTC, a named regional zone, or a fixed offset for each workload and document why.
- Set the startup default and the application session explicitly; do not rely on an accidental
SYSTEMvalue. - Load and maintain MySQL timezone tables before using named zones.
- Restart after operating-system timezone rule changes, then repeat the checks.
- Verify behavior after connection-pool reuse, replication, failover, and container replacement.
Bottom line
Different times are a configuration mismatch, not a mysterious MySQL calculation error. Identify the host, global, and session layers; make UTC or the required named zone explicit; understand how TIMESTAMP and DATETIME represent values; and keep every server and connection consistent. That process fixes current displays without silently corrupting historical data.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
