We've developed an in-house application, with several related crons that execute at some time during the day. These crons are designed in such a way that they make sure that they ignore, for example, being executed before 7:00 am, or only execute once a day or week.
This particular approach is chosen to ensure that the task at hand is not executed when nobody is at the office (for example), but also allows to run every X minutes to 'retry' if the cron somehow failed to execute (and ensures execution when the server has some downtime as an added bonus).
Furthermore, some parts of the software rely on the current system's date, to inform one of the API's used of some action, like deleting a remote object that has expired in the program. These parts are either invoked by the crons, by some user (where a check is done on the current time) or a remote API.
We are now in the stage to test this application with several end-users and we want to create a fully operational environment. However, as most cycles in the application take a year or so to complete, we are looking for ways to make the server time 'run faster', i.e. one day per real-world minute or so. However, we also need to visit every hour of the day to make sure everything runs smoothly. Effectively, the server time would be increased 1440 times during the test.
Is there some 'nice' way to accomplish this on a Linux (CentOS) server, or is the only way to let another cronjob increase the time? Are there disadvantages of such an approach?