Setting the Clock Forward or Back
Occasionally in software development you need to set the clock forward, or back, to test functionality or duplicate a reported problem.
My advice to you is to do this inside a virtual machine, not on your main development system.
Messing with the clock is something that can have a pretty big impact on your system, and you should think carefully before setting the clock ahead a few months to see if your automatic code (for example) kicks in properly.
When your system moves forwards and then backwards in time, you’re breaking the trusim that time moves in one direction. Many things compare the dates of two things to see which one is newer. For example, if you build an application with the clock foward (say you found a bug in your date sensitive code, fixed it, and you’re building to test the fix), then your .cpp file and .obj file will now be dated in the future. Now, when you set the clock back to normal, and edit your .cpp file, your “updated” source file will still far older than the .obj file, and so it won’t get built.
Some of the bad things that can happen:
- Trial versions or timed licenses on your software can incorrectly decide that you’re no longer allowed to use your software. This is especially true of moving the clock backwards – often the anti-piracy code sees this as an attempt to get around a timed trial and locks you out of the application.
- SSL certificates will expire. They will start working again when you set the clock back.
- Your calendaring application will decide to “remind” you of the hundreds of recurring appointments you missed during the last “year”.
- Your timed backups will kick in, in “full backup” mode because it’s been so long since you last did a backup.
- If you’re on a domain, your clock will be set back to the normal time. This makes testing difficult since you don’t know when the clock moves back.
- Need to change your password every 90 days? My, how time flies.
It’s no fun.
If you need to test this sort of thing occasionally in your own application, then build in a way to feed the app a bogus date. Centralize the date checking, and have a manual override that you can specify.
And if you can’t do that, run in a VM that’s not on a domain.