> Wierd timeout errors clumped around 1:00 am every few nights
You always can shift clock automatically (on Linux).
Obviously a problem of this sort is not due to the mere numerical value of the time but rather some daily scheduled process that runs around 1am (perhaps a database backup) which interferes with the web app in some way. This sort of thing can be simulated but it's a non-trivial task and it's probably better to apply those efforts in other ways (by diagnosing the problem, putting in place a performance monitoring system, buying more hardware, etc.)
* find problem;
* identify root cause of the problem;
* write automated, semi-automated or manual test case, which will highlight problem;
* fix problem.
If you will not use test cases at development and staging stages, then you will just use your production environment for testing purposes. If your downtime cost you nothing - don't bother with test cases.
In our case, we had similar problem, so I created very simple test case in shell in less than 2 hours. We spent more than year until it was fully fixed.
You always can shift clock automatically (on Linux).
Obviously a problem of this sort is not due to the mere numerical value of the time but rather some daily scheduled process that runs around 1am (perhaps a database backup) which interferes with the web app in some way. This sort of thing can be simulated but it's a non-trivial task and it's probably better to apply those efforts in other ways (by diagnosing the problem, putting in place a performance monitoring system, buying more hardware, etc.)