Do you mean that you add an hour if the date you're trying to convert
exists BEFORE the time change? Because that's the real issue. If the
transaction takes place at say 12pm during DST it's going to be off an
hour if you check the same transaction at some point in the future when
DST isn't in effect.
I think the real solution here would be to look at the date being
converted and determine if it falls in DST or not... then convert
accordingly.
I was just hoping that someone out there (read: Macromedia) had already
taken this scenario into consideration and delt with it accordingly.
-Novak
-----Original Message-----
From: Tony Weeg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 11:19 AM
To: CF-Talk
Subject: RE: UTC and daylight savings time...
I do just about what you do
1. set a _javascript_ cookie with persons time zone
2. read that time zone with cookie. cf variable
3. compare with server time zone.
if server time zone is -4 I know we are in dst, if server time zone
is -5 I know we are in est.
4. if server time zone is 4. I add an hour, if its -5 I leave it alone.
5. it's a bit screwy, but it works.
...tony
tony weeg
senior web applications architect
navtrak, inc.
www.navtrak.net
[EMAIL PROTECTED]
410.548.2337
-----Original Message-----
From: cf-talk [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 1:53 PM
To: CF-Talk
Subject: UTC and daylight savings time...
While we're discussing best practices today I have a quick question
regarding time zones, UTC, etc, etc.
I believe that the preferred method of storing dates and times in your
database is in UTC. I have no problem running all of the servers in the
UTC
time zone even.
>From there it's a question of what's the best way to convert the UTC
back to the user's local time zone.
My practice has always been to use _javascript_ to determine the user's
time
zone offset and use that to calculate their local time from the UTC.
But one problem I foresee is after a time change (spring forward, fall
back).
Pretend for a moment that a transaction occurs on February 22nd, 2004 at
12:00pm
If I look up that transaction on February 25th the time will still show
12:00pm.
But what happens when I look up that transaction on May 1st, 2004? My
time
zone offset is now different by an hour. So, theoretically, the
transaction
from Feb 22nd will no longer return 12:00pm... It will be incorrect by
one
hour.
Does the built in ColdFusion function(s) account for this? Or would one
have to use some other method to ensure accuracy?
We already know DateDiff does some quirky stuff... So that's what got me
thinking about this scenario...
On a different note... A completely different solution might be to
calculate
the user's local time on the fly and store it in the database record at
that
specific moment in time. Of course this has it's own set of issues
too...
-Novak
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
