Daylight Savings Time and MySQL

For those that follow Daylight Savings Time in the US and Canada, watch out this weekend, because we “spring forward”!

The biggest caveat I have is: Do not arrive 1 hour late to work on Sunday or Monday.

As for MySQL, to test if you are fine, run:

SELECT @@global.time_zone;

If you get back “SYSTEM”, then MySQL is looking to the OS for timezone data, which is the default.

The real sanity check:

SELECT UNIX_TIMESTAMP('2007-03-11 02:00:00'), UNIX_TIMESTAMP('2007-03-11 03:00:00');

This should return the same value, even though you are feeding it different times, because this is when the 1 hr change occurs. If not, and you’ve played with timezone data, remember that timezone data is only loaded when MySQL starts, so if you haven’t restarted MySQL since you patched your OS, you need to do that.

This is mostly stolen from a MySQL list post I found here:

http://lists.mysql.com/mysql/205321

For those that follow Daylight Savings Time in the US and Canada, watch out this weekend, because we “spring forward”!

The biggest caveat I have is: Do not arrive 1 hour late to work on Sunday or Monday.

As for MySQL, to test if you are fine, run:

SELECT @@global.time_zone;

If you get back “SYSTEM”, then MySQL is looking to the OS for timezone data, which is the default.

The real sanity check:

SELECT UNIX_TIMESTAMP('2007-03-11 02:00:00'), UNIX_TIMESTAMP('2007-03-11 03:00:00');

This should return the same value, even though you are feeding it different times, because this is when the 1 hr change occurs. If not, and you’ve played with timezone data, remember that timezone data is only loaded when MySQL starts, so if you haven’t restarted MySQL since you patched your OS, you need to do that.

This is mostly stolen from a MySQL list post I found here:

http://lists.mysql.com/mysql/205321

Comments are closed.