Change sysdate and keep the clock ticking

Question

Hi All
We wanted to test some reports which gets processed (there are other date based calculations while processing) monthly, quarterly etc and for that we wanted the sysdate to get changed to a particular date and then the clock should go ticking.
Is there any other way other than changing the OS date. Because of organizational issues we cannot change OS dates. We tried the FIXED_DATE, but the clock is not ticking after that.
Please help
Thanks in Advance
-Georgey

Answer 1

Hi, Georgey,
Georgey wrote:
Hi All
We wanted to test some reports which gets processed (there are other date based calculations while processing) monthly, quarterly etc and for that we wanted the sysdate to get changed to a particular date and then the clock should go ticking. SYSDATE is taken from the operating system. If you reset the date on the database server's OS, Oracle will use the new date. Of course, anything else that runs on the database server will use the new date, too.
Is there any other way other than changing the OS date. Because of organizational issues we cannot change OS dates. We tried the FIXED_DATE, but the clock is not ticking after that. Good try, but, unfortunately, that doesn't work.
You might replace all references to SYSDATE in your code with references to a user-defined function, that returns SYSDATE plus (or minus) a constant. That will make your code slower, but that might not be an issue for testing. That probably will be n issue in Production, however, so change all the references to your user-defined function back to SYSDATE before moving the code to production.
Edited by: Frank Kulash on Sep 27, 2012 12:49 PM
Here's an example of the user-defined function:
CREATE OR REPLACE FUNCTION my_sysdate
(  in_dt  IN DATE  DEFAULT DATE '2013-01-01'
RETURN DATE
AS
--     my_sysdate returns the actual date and time (as returned by SYSDATE),
--     asif today started on in_dt.  For example, if it is actually 12:00
--     noon on September 27, 2012, then
--     my_sysdate               returns 12:00 noon on January 1, 2013
--     my_sysdate (DATE '2012-09-01')     returns 12:00 noon on September 1, 2012
--     my_sysdate ( DATE '2012-09-01'
--             + (2/24)
--             )     returns 2:00 PM on September 1, 2012
BEGIN
     RETURN  SYSDATE - ( TRUNC (SYSDATE)
                 - in_dt
END;
/If you use SQL*Plus, you can define a substitution variable at the beginning of each sript, that tells whether you want to use the real SYSDATE or your user_defined fucntion.
For example:
-- Only the last of these next 2 statemnts has any effect:
DEFINE     sysdate_function = SYSDATE
DEFINE     sysdate_function = "my_sysdate (DATE '2012-10-01')"
SELECT     CASE
         WHEN  order_date > &sysdate_fucntion
         THEN  'Future'
         WHEN  order_date > &sysdate_fucntion - 7
         THEN  'This week'
         WHEN  order_date > ADD_MONTHS (&sysdate_fucntion, -1)
         THEN  ...
     END        AS order_date_grp
...When you're ready to move this to Production, just change the DEFINE statement at the beginning. No matter how many times &sysdate_function is referenced in the script, the specified function will be called. This will not hurt performance, because, when the code is compiled, it will be compiled with the actual (fast) SYSDATE when that is what you want.