new and improved timezone CFC
our code re-working frenzy continues. trying to squeeze more speed out of our venerable timezone CFC (circa AD 2003), we revisited each method looking for "dumb things". one thing we noticed was its use of the gregorian calendar to determine a timezone's offset. why we did it that way has long since been forgotten (but probably someone who knew java better than we did told us to, we were looking at using other calendars, the fact that it worked at all was a novelty, etc.).in any case functions (castFromUTC/castToUTC/etc) that used code like this:
// get selected timezone
tZ=tzObj.getTimeZone(arguments.thisTZ);
// set gregorian calendar to selected timezone
gregorianObj.setTimeZone(tZ);
// set gregorian calendar to selected datetime
gregorianObj.setTime(arguments.thisDate);
// calculate offset
thisOffset=(gregorianObj.get(gregorianObj.DST_OFFSET)/1000) +
(gregorianObj.get(gregorianObj.ZONE_OFFSET)/1000);
return dateAdd("s",thisOffset,thisDate);
were re-worked to use:
// get selected timezone
var timezone=tzObj.getTimeZone(arguments.thisTZ);
// get offset in hours, also considers DST
var thisOffset=
timezone.getOffset(javacast("long",arguments.thisDate))/3600000;
// send cast date back to caller
return dateAdd("h",thisOffset,arguments.thisDate);
and sped things up 2x-3x. you can see the new CFC in action here.
posted by Paul Hastings @ 12:19 AM
2 Comments:
Is there a CF CFC to look up the java time zone string based on city/province/state/country?
there are rather a lot of regional timezones already present in the olsen data, but no, no CFCs or anything like that to do detailed look ups. i suppose we could do something with a decent GIS webservice. is it really critical?
Post a Comment
<< Home