Trust me, the JVM issue has had a lot of man hours invested in trying to fix it and the only solution found was to go to CF8 and that was just more fuel to the people pushing to trashcan CF completely and go to .NET Actually in all reality I do not see us needing to worry about it much since I believe any of our apps that need to worry about this will end up getting retired in less than a years time as Exchange, SharePoint and a whole slew of other MS products are pushed out and CF is trashcanned as quickly as the IT Architects can make it happen.
All CF does is display a character from the database, it has no clue that the character is a date/time within that string. CF does collect a time in the form of HH:MI DD-MMM-YYYY but it never considers anything in regards to TZ's because really the application does not care about that at all. all of the business logic around the TZ's is done in the database. The database sees what physical location is dealing with a record insert/update and the database looks at its mapping between a physical location and its TZ system tables and then it deals with any manipulation/calculations that need to be done from there. Since Oracle runs on top of Java, I'd imagine they too are on top of things. The nice thing about us relying on Oracle and not CF is we know CF has issues due to conflicts outside of its control, the Oracle boxes have yet to present a problem and if they did I have far greater confidence in the people administering those boxes vs the whoever the contractor is this week for the CF boxes. On Dec 20, 2007 11:36 AM, Paul Hastings <[EMAIL PROTECTED]> wrote: > Aaron Rouse wrote: > > True, but willing to take the risk. > > if cf touches any of your datetimes along the way, then you've fallen into > tz > hell. if your servers are in tz that implement DST scan your cf touched > "UTC" > datetimes & you won't find *any* on the cusp of DST, they were all rolled > into > DST. it won't matter that you're converting to UTC, cf doesn't know about > any tz > except the server's. > > > I actually just had one of our systems adjusted for timezone differences > and > > need to see how he went about it. I know he used the Oracle TZ table > and > > whether that's a good idea depends on what tz you need & whether oracle is > on > top of things. > > > As a rule we do not use CF(or the Java it is running on) for TZ > > adjustments. We already have time problems with our CF7 boxes because > the > > core java & icu4j (ibm) are usually on top of this sort of stuff. > java/i18n > folks are are very picky about tz, fist fights often break out ;-) > > > JVM that adjusts for the TZ changes in the past 1-2 years conflicts with > our > > LDAPS cert which forces us to run on an older JVM. > > um, i'd try to fix that ;-) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;160198600;22374440;w Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:295203 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
