Unless you’ve been living on a desert island for the last year, you’ve probably heard that you’ll need to upgrade ColdFusion’s JVM (java virtual machine) before March 11th 2007. Thats when daylight savings time takes effect this year. Since the dates have shifted in 2007, anything that is aware of daylight savings time will require an update. This includes your operating system (Windows, Linux, OSX, etc.), and Java since it has its own internal timezone tables.
And if you use NTP (network time protocol) to set the time on your servers from an internet time server, don’t think you’re immune. NTP simply syncs your internal UTC (universal time) clock with a UTC clock on the internet. Your timezone tables then determine your actual local time, based on your UTC offset, which changes during daylight savings time.
Updating ColdFusion’s JVM is very easy. The version of java that ColdFusion ships with is 1.4.2_09. You can see this if you login to your CF Administrator, then click on SYSTEM INFORMATION at the top of the page.
Also note the Java Home setting, we’ll be changing that soon.
Adobe is recommending moving to version 1.4.2_11 of the java runtime. ColdFusion is certified to run on that version, although I have heard reports of it running just fine on later versions. But if you want to be able to use Adobe support – better stick to the _11 version.
You can download the necessary java runtime from http://java.sun.com/products/archive/index.html. Go down to the J2SDK/J2RE – 1.4 section, and choose the 1.4.2_11 version from the drop down box next to it. On the next page, click the Download J2SDK link. Accept the license agreement, then click on either the Windows or Linux download link.
For Windows, download the installer and run it, following the usual windows installer prompts. By default the new JRE will be installed in C:\j2sdk1.4.2_11
On Linux (RedHat, CentOS, Fedora or similar), download the rpm.bin file, then run the bin file – that is, at command shell, type
./j2sdk-1_4_2_11-linux-i586-rpm.bin in the directory you downloaded the file in. You may need to add execute permissions, if so you can do that with
chmod 700 j2sdk-1_4_2_11-linux-i586-rpm.bin. After you page through and agree to the license, you will be left with the actual rpm file in the local directory. Install it like
rpm -ivh j2sdk-1_4_2_11-linux-i586-rpm. Your new JRE will be installed in /usr/java/j2sdk1.4.2_11.
Now that the new java is installed, we just need to point ColdFusion to it. It is possible to change the java path in the CF administrator, but I don’t recommend it. First of all if you’ve made any hand edits to the jvm.config file, changing the java path through the administrator will wipe them out. Secondly, if something goes wrong you’ll need to put the old setting back, which you won’t be able to do through the administrator since ColdFusion won’t be running anymore.
So its best to just edit the jvm.config file directly. On Linux this is usually located at /opt/coldfusionmx7/runtime/bin/jvm.config. On Windows, look for C:\CFusionMX7\runtime\bin\jvm.config.
Near the top of the file you’ll see the java.home= line. Comment that out by placing a pound sign in front of it. Add a new line below it pointing java.home to our new JVM. The section of the file should look like this –
Save the file, then restart ColdFusion. If you have problems getting ColdFusion to start up, go back into the file and remove your new line, and uncomment the old line. ColdFusion should then be able to start.
To verify you are running on the new version, log into the administrator again and look at the system information page.
Note that Java Home now references your new JRE installation. IMPORTANT NOTE – if you’ve imported any certificates into your java keystore, you’ll need to reimport them into your new Java installation. Importing a cert into the keystore usually happens as a result of needing to cfhttp to a self-signed-certificate SSL webserver.
Don’t forget to patch your OS, too. You can tell if your Linux machine has been updated by running
zdump -v /etc/localtime | grep 2007. If you see some lines referencing March 11, you are good to go. If not, you can update your timezone tables by running the command
yum update tzdata.
For Windows users – if you use Windows Update regularly I imagine you have the necessary update installed. If not, you can download the necessary update from http://support.microsoft.com/gp/cp_dst.
MySQL may or may not need to be updated, it can depend on the version and when it was installed. An easy way to check is to run this query:
SELECT UNIX_TIMESTAMP('2007-03-11 02:00:00'), UNIX_TIMESTAMP('2007-03-11 03:00:00')
You should get back the same timestamp for both results, even though you are specifying different times – 2:00am and 3:00am. This is because the 1hr time change occurs at 2:00am.
If you get back different values, your MySQL timezone tables may need reloaded. You can do that with this command:
mysql_tzinfo_to_sql /usr/share/zoneinfo|mysql mysql -p