The issue has come up before on the list and here is the reasoning: Take 5 a.m. on the day before DST kicks in. Then 5 a.m. on the day that DST kicks in. Logically, you'd think that one day had elapsed. Well, that's true if you are using a day as your unit of measurement, but that isn't how Java does it. Ask yourself this question: how many hours elapsed? Well, 5 a.m. on the first day until 2 a.m. on the next day is 21 hours. But then the clocks jump forward to 3 a.m. The hour between 2 and 3 a.m. never happens, it disappears. Then it counts from 3 a.m. to 5 a.m. which is another 2 hours. So 21 + 2 = 23 hours, not 24. Down in the JVM, it is actually counting in milliseconds, not hours, so the hour that is missing is actually 3,600,000 milliseconds, but the principle is the same. When you ask Java "how many days have elapsed from 5 am this day to 5 am the following day" and that spans the time change, Java is going to reply 0 because a whole day has not elapsed.
In your particular example, you have servers in two places, one that observes daylight savings and one which does not. The difference you are seeing is a result of that. Going back to my previous example, lets take the server on the East Coast (that observes daylight savings) and add 24 hours to the 5 a.m. time the day before the time change. Internally, it adds 21 hours, hits 2 a.m. (when the time shift happens and it is suddenly 3 a.m.), then adds 3 hours to 3 a.m. giving you 6 a.m. The same example in Arizona, where they don't observe daylight savings: it adds 21 hours to get to 2 a.m., no time shift happens because of daylight savings, so it then adds the other 3 hours and gets 2 a.m. + 3 hours = 5 a.m. Hence, adding the same number of time units to the same starting time ends up producing two different resulting time values because one server skips over a lost hour during the dst transition. Confusing as hell, but internally consistent at least. Cheers, Judah On Thu, Apr 22, 2010 at 9:35 AM, Tom McNeer <[email protected]> wrote: > > Okay, > > So - it wasn't a JVM issue. Updating it did not change the results. > > And Steve was right, in a way. But I still don't understand why it should be > this way. > > First, Steve, I understand what you're saying about "whenever you display a > time." But in practice, I'm not displaying a time at all. I'm simply > creating a date/time value and adding a number of seconds to it, then > inserting into a database. > > So to my way of thinking - and according to every doc I've ever read - the > dateAdd function should do exactly what you tell it to do: just add the > increments to the original date. > > But what's happening DOES involve DST - though not the time zone. I don't > know why. It shouldn't. But it does, at least in CF9. > > Try this for yourself: Daylight Savings Time began at 2:00 AM Eastern on > March 14, 2010. So run the following: > > <cfset myDate = createDate(2010,3,14) /> > <cfdump var="#myDate#" /><br><br> > <cfset myDate2 = DateAdd('s',1271779666,myDate)> > <cfdump var="#myDate2#" /><br><br> > > myDate is two hours _before_ DST went into effect. On two different CF9 > servers, one on EDT, the other on CDT, the result for myDate2 was: > {ts '2050-07-01 17:07:46'} > > Now change the createDate to (2010,3,15) - _after_ DST went into effect. On > the same servers, the result was: > {ts '2050-07-02 16:07:46'} > > The original date was changed by a day. But the result of the dateAdd > statement changed by 23 hours. > > I wish I could test this on CF8 and/or 7, but the only servers with those > versions to which I have access are in Arizona, where they don't use DST. > Those servers return the 16:07:46 timestamp. But without having the machines > set to DST, I can't tell if CF is acting differently or not. > > If someone has access to those versions on a DST machine, please try this > and see what you get. I'd really be curious to know if this is a CF9 thing. > > Maybe I've just misunderstood how dateAdd works - although the docs simply > say "Adds units of time to a date." There's no mention of DST affecting it. > But it's certainly doing so. > > So in brief: when you dateAdd, the result will be affected by DST - at > least, based on whether your added timespan crosses the DST threshhold for > the current year. I have no idea if it tries to figure out whether the > resulting date/time is during DST or not. > > In most instances, this might not even be noticed. But in my case, where I'm > receiving a timestamp from an external device as a Unix epoch time, then > converting it to a date/time object by adding the epoch time to the date of > 1/1/1970, the result is not what I want, since all I'm trying to do is > recreate the time from the original device. The DST addition causes the > timestamp to be wrong by an hour. > > Frustrating, but at least I now understand what's happening. Hope this will > help someone else avoid the same frustration. > > > > -- > Thanks, > > Tom > > Tom McNeer > MediumCool > http://www.mediumcool.com > 1735 Johnson Road NE > Atlanta, GA 30306 > 404.589.0560 > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:333087 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
