•If you replace the system’s /etc/localtime  time zone file with a version that uses rules differing from those in effect at mysqld  startup, restart mysqld  so that it uses the updated rules. Otherwise, mysqld might not notice when the system changes its time. 

•If you use named time zones with MySQL, make sure that the time zone tables in the mysql  database are up to date: 

•If your system has its own zoneinfo database, reload the MySQL time zone tables whenever the zoneinfo database is updated. 

•For systems that do not have their own zoneinfo database, check the MySQL Developer Zone for updates. When a new update is available, download it and use it to replace the content of your current time zone tables. 

For instructions for both methods, see Populating the Time Zone Tables. mysqld  caches time zone information that it looks up, so after updating the time zone tables, restart mysqld  to make sure that it does not continue to serve outdated time zone data. 

If you are uncertain whether named time zones are available, for use either as the server’s time zone setting or by clients that set their own time zone, check whether your time zone tables are empty. The following query determines whether the table that contains time zone names has any rows: 

mysql> SELECT COUNT(*) FROM mysql.time_zone_name; +----------+ | COUNT(*) | +----------+ | 0 | +----------+ 

A count of zero indicates that the table is empty. In this case, no applications currently are using named time zones, and you need not update the tables (unless you want to enable named time zone support). A count greater than zero indicates that the table is not empty and that its contents are available to be used for named time zone support. In this case, be sure to reload your time zone tables so that applications that use named time zones can obtain correct query results. 

To check whether your MySQL installation is updated properly for a change in Daylight Saving Time rules, use a test like the one following. The example uses values that are appropriate for the 2007 DST 1-hour change that occurs in the United States on March 11 at 2 a.m. 

The test uses this query: 

SELECT CONVERT_TZ(’2007-03-11 2:00:00’,’US/Eastern’,’US/Central’) AS time1, CONVERT_TZ(’2007-03-11 3:00:00’,’US/Eastern’,’US/Central’) AS time2; 

The two time values indicate the times at which the DST change occurs, and the use of named time zones requires that the time zone tables be used. The desired result is that both queries return the same result (the input time, converted to the equivalent value in the ’US/Central’ time zone). 

Before updating the time zone tables, you see an incorrect result like this: 

+---------------------+---------------------+ | time1 | time2 | +---------------------+---------------------+ | 2007-03-11 01:00:00 | 2007-03-11 02:00:00 | +---------------------+---------------------+ 

After updating the tables, you should see the correct result: 

