Summersault Weblog

Now that the dust has settled on Indiana’s switch to Daylight Savings Time on April 2nd, 2006. here are some notes on what worked for us at Summersault.

As a web hosting and development provider, we have been located in Richmond, Indiana since 1997. We have never had to update our time zone configuration or even change our clocks until now.

Although there already some good resources about coping with the change, my search turned up a number of additional resources I thought would be useful to share.

General notes

Our Unix-based systems have a tool called zdump which allows us to see a particular time zone definition. By visually inspecting the time zone file for our region, I can see if it includes a notation for the upcoming change. That command is:

zdump -v /usr/share/zoneinfo/America/Indiana/Indianapolis

Note that the zone “America/Indianapolis” is no longer referenced in the “zone.tab”. It may be correct for older sets of data, but “America/Indiana/Indianapolis” appears to be the official current replacement.

Time zone updates on FreeBSD

Here’s the basic recipe that should work to update time zone definitions on FreeBSD servers:


fetch ftp://elsie.nci.nih.gov/pub/tzdata2006b.tar.gz
# I’m only getting updated data from the ‘northamerica’ file. If you are in
# another country with a time zone change, be sure to select a different file here!
tar -xzvf tzdata2006b.tar.gz northamerica zone.tab
zic northamerica
chmod 600 /usr/share/zoneinfo/zone.tab
cp zone.tab /usr/share/zoneinfo/zone.tab
tzsetup


Take heed of the BUGS section of from the tzsetup documentation:

Programs which are already running when tzsetup creates or updates /etc/localtime will not reflect the updated timezone. When the system is first configured for a non-UTC hardware clock, it is necessary to run adjkerntz(8) (which normally happens as a part of system startup) in order to update the kernel’s idea of the correct timezone offset.

Due that limitation, we needed to restart key services such as Apache and PostgreSQL and cron to make sure they saw the updated time zone information.

Time zone updates for Cisco routers

The following configuration changes needed to be made to inform our Cisco router of the change:


config t
clock summer-time EDT recurring


Here’s Cisco’s official documentation about setting time zones on this product.

Time zone updates for the Perl language

Time zone information is embedded in the DateTime::TimeZone module, which we used in some places. Simply upgrading to the most recent version was the solution.

Time zone updates for the PHP language

PHP has a rather complex way to determine the current time zone. For our installations, it appears that PHP gets the time zone from the operating system, so no changes were needed for us, beyond restarting Apache.

Time zone updates for the WordPress blogging software

WordPress 1.5 tracks the time zone internally, so it needed special attention. We chose to install
in the WordPress time zone plugin, which causes WordPress
to refer to the operating system for the time zone, meaning that no special changes for WordPress should
be needed in the future. Perhaps if you are supporting WordPress bloggers across several time zones, another
solution would work better.

Time zone updates for the MySQL database

I was able to check MySQL’s notion of the current time zone with a couple of commands:


SELECT @@time_zone;
SELECT NOW();


Again, in our case it appears to be referencing the operating systems notion of a time zone, so no changes were made. See MySQL’s official documentation on time zone support for details.

Time zone updates for the PostgreSQL database

Versions 7.3 and 7.4 get their time zone from the operating system, while the 8.0.x and 8.1.x releases store the data internally.

7.3 and 7.4 get it from the OS. 8.0.x and 8.1.x have copies of the timezone data. Those that it get from the OS need to be restarted need to be restarted to see the change.

Update: Asterisk

For the Asterisk phone system and our SIP-based phones, we needed to make the these changes to cope with the changes that took affect on March 11th, 2007:

In /home/PlcmSpIp/sip.cfg, the following values needed to be updated:


tcpIpApp.sntp.daylightSavings.stop.date=”4″
tcpIpApp.sntp.daylightSavings.stop.month=”11″
tcpIpApp.sntp.daylightSavings.start.date=”11″
tcpIpApp.sntp.daylightSavings.start.month=”3″


In conclusion

I hope these notes were helpful. Good luck with your own time zone changes, and post any comments or corrections below.

---

This entry was posted on Tuesday, April 4th, 2006 at 12:50 pm and is filed under Sysadmin / Hosting. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.