Pardon Me, Do You Have the Time?

I’ve recently moved my sites over to a new VPS, with a new CF9 Professional install. This blog has been there for about a month now, and there’s been an issue that I never noticed until today.

There’s a new site that I’ve been working on, and is just about complete. One of the last things I wanted to add was a “dateLastUpdated” column into one of the database tables, which I did this morning. I’m passing ColdFusion’s #now()# value as the dateLastUpdated. I know that it’s generally considered better practice to use a database-specific variable (e.g. getDate() in SQL Server or CURRENT_TIMESTAMP in mySQL), but I didn’t want the column populated when the record was initially created, so I didn’t set it as a default value on the column. I’m using ColdFusion 9′s ORM integration, which I’m new to, so the path of least resistance was for me to just pass now() as the value. It’s not going to be a high-traffic site, so I wasn’t particularly worried about whatever performance implications might result from not “letting the database do the work”.

It should have been straightforward enough, but when I went to test, I noticed that the dateLastUpdated value was 12 hours in the future. I VPN’d into the VPS and verified the system time was correct (same as my local time here in AZ). I recalled that there was a DST bug in a previous JVM, but since the time difference was greater than an hour, I assumed this wasn’t a DST issue. After some googling, I found a post on the Adobe Forums, with a very helpful answer by Paul Hastings (of course… Paul’s very well known for his knowledge of all things i18n/timezone related, and deservedly so).

Paul suggested running the following code to see what timezone ColdFusion -thinks- it’s in, based on the JVM:

<cfscript>
	tz=createObject("java","java.util.TimeZone").getDefault();
	tzName=tz.getDisplayname(true, tz.LONG); // default tz long name, DST if used
	jre=createObject("java","java.lang.System");
	JREname=jre.getProperty("java.runtime.name");
	JREversion=jre.getProperty("java.runtime.version");
	writeoutput("JRE: #JREname# #JREVersion#<br />timezone: #tzName#");
</cfscript>

Running the script above output the following:

JRE: Java(TM) SE Runtime Environment 1.6.0_17-b04
timezone: Pakistan Summer Time

O_o

In 15 years of using ColdFusion, I’d never run into this. I’ve never installed CF to find that the default timezone seems to be Pakistan Summer Time. In fact, I’d been under the impression that ColdFusion simply used the server’s system time. But I guess given the DST bug mentioned earlier, I should have been aware that it does not.

So to resolve this, I took the following steps:

  • Logged into the ColdFusion Administrator on my VPS
  • Clicked the “Java and JVM” link under “Server Settings” in the navigation on the left.
  • Appended the following string to the JVM Arguments:
    Duser.timezone=US/Arizona
  • Saved changes and restarted the ColdFusion service.

I ran the code snippet provided by Paul a second time, and now the output looked like:

JRE: Java(TM) SE Runtime Environment 1.6.0_17-b04
timezone: Mountain Daylight Time

Much better. Also verified that outputting #now()# displayed the correct time. Everything’s sorted… but I’m still a bit curious as to whether or not this is a “known issue”… are all CF9 installs defaulting to Pakistan Summer Time as the time zone? I’d imagine we’d have heard more about it if that were the case. Has anybody else run into this recently?

In any event… if you’re noticing that ColdFusion is not displaying the correct values for #now()#, take the code above for a spin and see what time zone your ColdFusion server thinks it’s in, and update your JVM arguments accordingly.