I was recently trying to test a system for a client that was trying to do some year end testing. In order to do this testing in the past they use to simply use the Oracle Database function “FIXED_DATE” to future date their database. When you use the FIXED_DATE feature it effects the SYSDATE variable and returns a date that is not the date of the operating system.

Unfortunately, with the more current releases of PeopleSoft, they have changed several of their system calls from SYSDATE to SYSTIMESTAMP. For some reason SYSTIMESTAMP is NOT effected by the FIXED_DATE override parameter, and from everything I have read there is no override parameter for changing the SYSTIMESTAMP. This leads to the problem of how to make future date testing work within PeopleSoft.

The only real solution is to future date the operating system. However, there are some real concerns that can come with this idea. I personally would highly recommend that you clone the server you are working on and use the cloned machine for this future date testing.

My testing system is stored on RackSpace servers, and when I made the cloned server and tried to change the OS date, it said it changed it, but when you looked again, it was still the current date/time. It turned out that the RackSpace system uses XEN on the RHEL OS to keep the server times in sync. I found the best way to change this was to add the sysctl parameter:

xen/independent_wallclock = 1

Once, I rebooted the server, I had no issue controlling the OS clock.