Date change testing

[Oliver White]

We have a problem which I am sure must be fairly common. We need to test that our software functions correctly for specific dates. For a complete test, we set the system date to a specific date and run the test. With our recent server consolidation, this becomes very difficult, as we do not want to affect other environments on the same server.

Is there a software product or other solution that will allow us to get a certain set of processes to see a different date from the rest? It would need to be able to fool Oracle and cron.

One solution would be v-pars, but it seems a pretty heavy-weight solution for what we want to do. Are there any other options?

[A. Clay Stephenson]

Ultimately all of these talk to the time() system call and there is only one system time. Your best bet to minimize the impact would be to shut down all other databases / applications except the one under test. You have just found one of the things that a Sandbox (as opposed to a Test environment) is made to do.

[Bill Hassell]

If you are testing for Daylight Saving changes, you're in luck. HP-UX allows you to define *any* timezone you like. You can invent a new one, even use your own initials if you want (like Aho, Weinberger and Kernighan, aka, awk)! Seriously, all date/time on HP-UX is kept as GMT/Zulu and never jumps for Daylight Saving or timezones. Instead, a table, /usr/lib/tztab defines each timezone and the rules about time changes. System calls to ask for the current time go through the tztab entry for the current value of TZ. For example:

TZ=EST5EDT date
TZ=PST8PDT date
TZ=GMT date

So if your testing only involves Daylight Saving then use TZ to set a new timezone. If testing involves dates that are days or weeks in the past or future, then you'll need a separate machine as the date/time is a basic kernel service.