ColdFusion and 2007 DST changes
Related Categories: ColdFusion
The Energery Policy Act of 2005 officially changes the start and end dates for Daylight Savings Time (DST) in the US this year (2007). DST will start at 2:00AM on the 2nd Sunday in March (03/11/2007) and end the 1st Sunday in November (11/04/2007). These dates will affect all versions of ColdFusion (5.0-MX 7).
This will cause issues with date/time calculations in ColdFusion. Some blogs have already posted notes on this. Adobe has published technotes dealing with the DST changes for ColdFusion:
- Technote kb400365, ColdFusion 5: How to ensure correct UTC Time Conversion for U.S. Daylight Saving Time changes in 2007
- Technote d2ab4470, ColdFusion MX/JRun and U.S. Daylight Savings Time changes in 2007
Workarounds
For CFMX 6.x-7.x, you need to upgrade to Sun JVM 1.4.2_11 or later: see Sun's note. Download the dstDates.zip to verify your update.For CF 5.0, you need to first apply the operating system DST-related patches. This will fix the issue for every date/time function except dateConvert(). UTC conversions will be off by an hour during the new DST periods --i.e. from March 11 (new DST start) - April 1 (old DST start), CF 5 is an hour ahead for Local2UTC and for the UTC2Local CF 5 is an hour behind; and from October 28 (old DST end) - November 4 (new DST end), CF 5 reverts to an hour ahead for Local2UTC, and an hour behind for UTC2Local. The technote has my work around code in it, here's the tag based version:
<cfset dateObj = now() />
<cfif cfTZ.isDSTOn>
<cfset utcDate = dateAdd('h', -1, dateConvert("Local2UTC", dateObj)) />
<cfset localDate = dateAdd('h', 1, dateConvert("UTC2Local", dateObj)) />
<cfelse>
<cfset utcdate= dateConvert("Local2UTC", dateobj) />
<cfset localDate = dateConvert("UTC2Local", dateObj) />
</cfif>
Comments (18) | 
Print | 
Send | 
Download |
del.icio.us
| 
Digg It!
| 
Linking Blogs
[Add Comment] [Subscribe to Comments]
If my testing is correct, I have found a problem with this code.
I ran through 3 scenarios:
1. Original OS using standard CF dateConvert()
2. Patched OS using standard CF dateConvert()
3. Patched OS using this tag based code
I created a test matrix using server dates of: 2/15/2007, 3/15/2007 and 4/15/2007.
During each of those I then tested by inputing a UTC date of: 2/15/2007, 3/15/2007 and 4/15/2007.
This would capture Standard time, the new DST and the old DST.
I then looked for the correct offset when converting to local time (Pacific Time).
Scenario 1 and 2 had identical results where a UTC date of 3/15/2007 would not convert correctly. Makes sense, as we already know that DateCompare() has issues.
Scenaro 3 has some really strange results. Here are the results:
Server: 2/15/2007
UTC: 2/15 8hr diff normal
UTC: 3/15 8hr diff did not adjust**************
UTC: 4/15 7hr diff adjusted
Server: 3/15/2007
UTC: 2/15 7hr diff invalid adjust**************
UTC: 3/15 7hr diff adjusted
UTC: 4/15 6hr diff invalid adjust**************
Server: 4/15/2007
UTC: 2/15 7hr diff invalid adjust**************
UTC: 3/15 7hr diff adjusted
UTC: 4/15 6hr diff invalid adjust**************
I have the results from all 3 scenarios if needed.
Your code primarily tests if the server date is in DST and adjusts the math. I think the correct test is to test the input date and tweak the math if the input date is in the new DST 3 week periods.
I welcome your thoughts, as I'm still trying to get my head wrapped around this thing and maybe I goofed up somewhere. I did this real quick last night on a win2000 box and set up a VPS today just for this testing. Same results on both.
Thanks, Terry
For what it's worth, here's the workaround I'm planning to use. It assumes that you're in UTC-6 when not in daylight time, and that the clocks are adjusted by +1 hour when in daylight saving time. It also relies on some date functions from the great CFLib (http://www.cflib.org/library.cfm?ID=13).
It passed all my unit tests, but I make no warranties of accuracy :-).
function DF_UTCToLocal() {
var dUTC = Arguments[1];
var iTimeZoneOffset = -6;
var dDSTStartUTC = dateadd("h", 2 - iTimeZoneOffset, getDaylightSavingTimeStart(Year(dUTC)));
var dDSTEndUTC = dateadd("h", 2 - iTimeZoneOffset - 1, getDaylightSavingTimeEnd(Year(dUTC)));
if (dUTC gte dDSTStartUTC and dUTC lt dDSTEndUTC) {
return dateadd("h", iTimeZoneOffset + 1, dUTC);
} else {
return dateadd("h", iTimeZoneOffset, dUTC);
}
}
function DF_LocalToUTC() {
var dLocal = Arguments[1];
var iTimeZoneOffset = -6;
var dDSTStartLocal = dateadd("h", 3, getDaylightSavingTimeStart(Year(dLocal)));
var dDSTEndLocal = dateadd("h", 1, getDaylightSavingTimeEnd(Year(dLocal)));
if (dLocal gte dDSTStartLocal and dLocal lt dDSTEndLocal) {
return dateadd("h", -iTimeZoneOffset - 1, dLocal);
} else {
return dateadd("h", -iTimeZoneOffset, dLocal);
}
}
Thanks for your input. I will revisit the code and the technote very shortly.
But what if the machine needs to determine if DST will be in effect on machines that DO observe it? Seems like you'd need to add a parameter here to do the calculations for another timezone.
Does that make sense?
I've applied the jvm patch, but when I connect to oracle and do:
select LOCALTIMESTAMP from DUAL;
It returns the time in standard time. Apparently there is something in Cold Fusion's oracle driver that still thinks we're in standard time. I'm using ColdFusion Mx 6,1,0,83762, with sun JVM 1.4.2 with the DST patch applied.
http://www.dir-9.com
http://www.dir-9.com
http://www.automotive-repair-manual.net/