How to Fix Different Times in MySQL and the Server

When MySQL and the operating system show different times, first identify the layer that differs: the host clock and timezone, MySQL’s startup-detected system timezone, the server-wide default, or the timezone attached to your current connection. Run one diagnostic query, then set the intended policy explicitly. For most applications, keep instants in UTC, use TIMESTAMP for values that represent an instant, and convert to a named user timezone only when displaying it.

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 can disagree

MySQL does not have one universal clock setting. It exposes three related timezone layers:

#	Preview	Product	Price
1		PHP and MySQL Web Development: A Beginner’s Guide (Beginner's Guide)	$33.99	Buy on Amazon
2		The Witch's Cookbook: 50 Wickedly Delicious Witchcraft-Inspired Recipes	$9.99	Buy on Amazon
3		1001W - The Rudimental Cookbook - Book & MP3	$30.00	Buy on Amazon
4		Fritter Cookbook	$3.99	Buy on Amazon
5		The Complete Cast Iron Cookbook: A Tantalizing Collection of Over 240 Recipes for Your Cast-Iron...	$14.99	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

• System timezone: @@system_time_zone is detected from the operating system when the MySQL server starts.
• Global timezone: @@GLOBAL.time_zone is the default for new client connections. Unless you change it, the default is usually SYSTEM, meaning MySQL follows the host setting it detected.
• Session timezone: @@SESSION.time_zone belongs to one connection. A new connection inherits the global value, but an application can override it for that session.

These layers can diverge after a host migration, a daylight-saving rule change, a container image update, a connection-pool configuration change, or a server restart that occurs before the operating system timezone is corrected. A query can therefore be correct for its session while appearing wrong when compared with the host clock or another connection.

Oracle’s MySQL documentation describes the common symptom precisely: if SELECT NOW() returns UTC instead of local time, the server must be told which timezone to use. The fix is configuration, not a different clock function.

#1 Best Overall

Sale

PHP and MySQL Web Development: A Beginner’s Guide (Beginner's Guide)

$33.99

Buy on Amazon

Diagnose the mismatch before changing anything

Run this query in the same client or application connection that reports the wrong value:

SELECT
  @@system_time_zone,
  @@GLOBAL.time_zone,
  @@SESSION.time_zone;

SELECT
  NOW(),
  UTC_TIMESTAMP(),
  CURRENT_TIMESTAMP();

The first result shows which timezone MySQL detected from the host, the server-wide default, and the current session setting. The second result lets you compare the session-sensitive current time with the UTC clock. NOW() and CURRENT_TIMESTAMP() are equivalent for this purpose.

Interpret the result

Compare the output with the operating system clock and timezone in the environment where the server process actually runs. For a container or virtual machine, that may not be the same environment as your laptop or the host machine you manage.

Choose a timezone policy first

Before applying a setting, decide what your timestamps mean:

• UTC policy: best for portable calculations, logs, APIs, and systems operating across regions. Store and compare instants in UTC, then convert for presentation.
• Named civil timezone: use a name such as Europe/Helsinki when business rules depend on local calendar time and daylight-saving transitions.
• Numeric offset: useful for a fixed offset when daylight-saving changes are deliberately irrelevant. An offset does not carry a region’s historical or future rule changes.

Do not use a local timezone merely because a developer’s workstation displays local time. A production database, replica, batch worker, and reporting tool should have a documented policy. The most predictable arrangement is an explicit UTC server default plus an explicit session timezone for any process that must present local civil time.

Fix the operating-system and startup layer

MySQL initializes @@system_time_zone when mysqld starts. If the operating-system timezone file was changed while MySQL was running, the process can continue using the old rules until it is restarted.

Rank #2

The Witch's Cookbook: 50 Wickedly Delicious Witchcraft-Inspired Recipes

$9.99

Buy on Amazon

1. Check the timezone configured in the operating system, container, virtual machine, or managed-instance environment that launches mysqld.
2. If the service is started with a TZ environment variable, set it to the intended zone before startup.
3. Where your deployment uses MySQL startup options, review the timezone-related --timezone or --default-time-zone setting.
4. Restart mysqld after changing the operating-system timezone file or startup environment.
5. Run the diagnostic query again and verify @@system_time_zone, the global value, and a fresh NOW() result.

A restart is important because MySQL reads the host’s timezone information at startup. Changing the host setting without restarting can leave the database process and the operating system reporting different rules.

Set MySQL’s global and session timezones

You can set an explicit server default at runtime:

SET GLOBAL time_zone = 'UTC';

That changes the default used by new connections. It does not retroactively rewrite the timezone setting of sessions that are already connected. Set the current connection separately:

SET time_zone = 'UTC';

For a local civil timezone, use a named zone:

SET GLOBAL time_zone = 'Europe/Helsinki';
SET time_zone = 'Europe/Helsinki';

For a fixed offset, use the offset format accepted by MySQL, for example:

SET time_zone = '+02:00';

Use the global command as a deliberate policy choice, not as a per-request substitute. In an application, issue the session command when each connection is created or checked out of a pool. Otherwise, one connection can retain a timezone left by a previous request.

A global setting changed at runtime may not survive a restart unless it is also placed in the server’s persistent configuration mechanism for your installation. The exact configuration file and service process differ by operating system and deployment, so verify the value after the next planned restart.

Load named timezone data when MySQL rejects a zone

Named zones such as Europe/Helsinki require populated MySQL timezone tables. If the data is missing, MySQL reports:

Rank #3

1001W - The Rudimental Cookbook - Book & MP3

$30.00

Buy on Amazon

ERROR 1298 (HY000): Unknown or incorrect time zone

Load the operating system’s zoneinfo data with MySQL’s mysql_tzinfo_to_sql utility. On platforms without a zoneinfo database, use the platform package or documented vendor method that supplies timezone data to MySQL.

1. Install or update the operating-system timezone database used by the server.
2. Run mysql_tzinfo_to_sql to convert that zoneinfo data into SQL and import it into MySQL’s timezone tables.
3. Restart mysqld.
4. Retry the named-zone assignment and run SELECT @@SESSION.time_zone; to confirm it.

Timezone rules change. Keep the tables maintained when your operating system receives a timezone-data update, especially for systems that schedule jobs or calculate dates in regions with changing daylight-saving legislation.

Understand TIMESTAMP and DATETIME before changing data

The column type determines whether MySQL performs timezone conversion:

If the same TIMESTAMP is selected in sessions using UTC and Europe/Helsinki, the displayed clock times can differ while the underlying instant is identical. That is expected conversion, not corruption. Conversely, a DATETIME value remains the same characters in every session, because MySQL does not know which timezone it represents.

Do not guess the timezone of legacy DATETIME rows

Changing the session timezone does not magically correct old DATETIME values. First establish which timezone the application used when each row was written. If the historical source timezone is unknown, there is no reliable offset to apply; guessing can shift records across dates and daylight-saving transitions.

For portable calculations, normalize known instants to UTC, perform arithmetic in UTC, and convert to the user’s named zone only at presentation time. Preserve the original value and document the assumed source timezone before performing a bulk conversion.

Rank #4

Fritter Cookbook

$3.99

Buy on Amazon

Make application connections deterministic

Database drivers and frameworks can set a session timezone after login. Connection pools make this especially easy to miss: a connection may be created with one setting, reused by another request, and retain a prior session override.

1. Set the server-wide default to the policy you want new connections to inherit.
2. In the connection initialization hook, execute SET time_zone = 'UTC' or the required named zone.
3. After a connection is returned to a pool, ensure application code cannot silently change the session timezone without restoring it.
4. Log the session timezone alongside timestamps when investigating an incident.
5. Test the same query through the production driver, not only through a command-line client.

Do not infer a user’s timezone from the database server’s location. Pass the user’s named zone as application context and convert only at the boundary where a human-facing date or time is rendered.

Replication and multiple servers

MySQL’s default assumption is that source and replica servers are in the same timezone. If they are not, a statement that evaluates NOW() or FROM_UNIXTIME() can produce an unexpected result on the replica. The host timezone, global setting, and session behavior must therefore be compatible across every server that executes time-sensitive statements.

• Prefer an explicit UTC policy on both source and replica.
• Do not rely on SYSTEM when hosts can be deployed in different regions.
• Check timezone settings after provisioning, failover, or a replica rebuild.
• Keep timezone tables synchronized when named zones are used.
• After changing an operating-system timezone file, restart each affected MySQL instance so it reloads the rules.

Replication alignment does not mean every user must see UTC. Keep server and replication processing deterministic, then set a presentation timezone in the client session or application layer.

Containers, virtual machines, and managed instances

In a container, the timezone available to MySQL comes from the container’s filesystem and environment, not necessarily from the physical host. A virtual machine can have its own clock and timezone configuration. A managed database service may restrict operating-system access while still exposing MySQL global and session settings.

• Document whether the intended policy is UTC or a named zone.
• Set the connection session explicitly, because the service’s host setting may not be under your control.
• Verify the timezone tables are present before using named zones.
• Include a timezone check in deployment and failover validation.

When you cannot change the host layer, an explicit session setting is usually the safest application-level fix. It does not, however, repair inconsistent replication or statements executed by other clients.

Best Value

Sale

The Complete Cast Iron Cookbook: A Tantalizing Collection of Over 240 Recipes for Your Cast-Iron Cookware (Complete Cookbook Collection)

$14.99

Buy on Amazon

Common symptoms and targeted fixes

NOW() shows UTC, but the server is in local time

Inspect @@SESSION.time_zone. If it is UTC, set the session to the intended named zone, or keep UTC and convert in the application. If it is SYSTEM while the result is still wrong, correct the host timezone and restart MySQL.

Changing SET GLOBAL did not fix my application

The application may be using an existing connection whose session timezone was set earlier. Reconnect or execute SET time_zone in the connection initialization hook. Confirm the value from the application connection itself.

A named timezone works on one server but not another

The servers have different timezone-table contents or different zoneinfo packages. Load current zoneinfo data into the failing server’s MySQL timezone tables, restart it, and verify the assignment again.

A TIMESTAMP appears to change when I change the session timezone

That display change is the documented behavior of TIMESTAMP: MySQL converts through UTC on storage and retrieval. Compare the values in UTC if you need to confirm that they represent the same instant.

Changing the timezone altered a DATETIME report unexpectedly

MySQL does not automatically convert DATETIME. The report may be applying application-side conversion, or the data was written under an undocumented local-time assumption. Establish the original source timezone before modifying rows.

A repeatable correction checklist

1. Run SELECT @@system_time_zone, @@GLOBAL.time_zone, @@SESSION.time_zone;.
2. Run SELECT NOW(), UTC_TIMESTAMP(), CURRENT_TIMESTAMP(); in the affected connection.
3. Compare those results with the clock and timezone of the environment running mysqld.
4. Choose UTC, a named civil zone, or a fixed numeric offset as the documented policy.
5. Correct the host environment and restart MySQL if the system layer is wrong.
6. Set SET GLOBAL time_zone = '...'; for new connections when an explicit server default is required.
7. Set SET time_zone = '...'; in every application session or pool initialization hook.
8. Load timezone tables if a named zone produces error 1298.
9. Review TIMESTAMP and DATETIME columns before attempting data conversion.
10. Validate source and replica settings together, especially where statements evaluate NOW() or FROM_UNIXTIME().

Recommended operating rule

Treat timezone as part of your database contract. Store and calculate known instants in UTC, keep the server and replication policy explicit, initialize every client session deliberately, and use named zones only when a user’s civil-time rules are required. That approach separates clock correctness from presentation preferences and prevents a host move or daylight-saving change from silently changing the meaning of your data.

Quick Recap

SaleBestseller No. 1

PHP and MySQL Web Development: A Beginner’s Guide (Beginner's Guide)

$33.99

Bestseller No. 2

The Witch's Cookbook: 50 Wickedly Delicious Witchcraft-Inspired Recipes

$9.99

Bestseller No. 3

1001W - The Rudimental Cookbook - Book & MP3

$30.00

Bestseller No. 4

Fritter Cookbook

$3.99

SaleBestseller No. 5

The Complete Cast Iron Cookbook: A Tantalizing Collection of Over 240 Recipes for Your Cast-Iron Cookware (Complete Cookbook Collection)

$14.99

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.