How to change NOW() without changing system date on the server

[Guest]

I am trying to find a way to test applications in the future month.  I want a test current month to January 2010. We want to limit 7 month range like 3 prev months and current month and 3 future months.

[craigkaminsky]

Is there a reason that the DateAdd function would not work for you? You can use it to set the various dates you might need:

<cfscript>

  current = Now();

  lastMonth = DateAdd('m',-1,current); // this would subtract one month from the current date

  nextMonth = DateAdd('m',1,current); // this would add one month from the current date

  // and so on with other dates

</cfscript>

There might be a reason why this doesn't work for you but wanted to throw it out there just in case.

[sittinghair]

We run 2 'local' times on our system, for users in the 2 countries. This method works for us....

In our Application.cfc onRequestStart() we set a request variable depending on the user locale.....

if (locale2)

     request.theLocalTime = DateAdd("h",-10,Now())

else

   request.theLocalTime = Now()

/

Then, we use request.theLocalTime in place of now() throughout our .cfm pages, and pass it as an argument where needed for cfc's in the application scope.

For testing, you could simply set the request.theLocalTime variable using DateAdd(), then change it back to now() when finished.

Hope this helps

Steve

[tooMuchTrouble]

first off tz have nothing to do w/locales. secondly, what happens if DST differs

between your server's tz & the user's? DST & even tz themselves are based on

political decisions.

[tclaremont]

Paul, you are right about the timezones and the locales not being an accurate matchup. I think the poster that is implementing this solution is in a position where he *knows* where the traffic is coming from. This might work OK on an intranet where your traffic is coming from a finite list of places.

As you implied though, if you were doing this for an unknown number of time zones and locales, the given solution would not be reliable.

[tooMuchTrouble]

....geez i really wish i could quote....

well he's got the offset fixed in his code, so he's going to be responsible

for keeping track of this. tz changes can come fast & furious (eg western

australia's last second DST, australian changes to host global sports events,

venezuela's tz two-step, etc.). it's not the best way to handle tz.

[tclaremont]

Oh, I am not arguing that at all, Paul. My point was more to explain to people reading this thread why the aforementioned solution might be "working" in spite of the fact that it is technically an incorrect solution.