Chrono MockChanging the system date to test an application
It is the oldest trick there is: set the Windows clock to the date you want to test, run the program, set it back. It works - and for as long as the clock is moved, it moves everything else on the machine too.
What actually moves with the clock
The system clock is not private to the program you are testing. Every process, service and network conversation on the machine reads the same one, so a change made for one test is a change made for all of them.
| What reads the clock | What happens when you move it |
|---|---|
| Domain logon and shared folders | Kerberos tolerates a clock difference of five minutes by default. Beyond that its tickets are refused, and logging on or opening a share fails. |
| Certificates and HTTPS | Whether a certificate is valid is decided against the clock. Set it past a certificate's end date and every connection that relies on it is refused as expired; set it back far enough and the certificate is not valid yet. |
| The Windows Time service | A domain-joined machine takes its time from a domain controller, and by default the service corrects the clock whatever the size of the difference. The date you set can be undone while you are still testing. |
| Everything that records a time | Files, logs, database rows and sent mail written while the clock is moved carry the test date, and keep it after you put the clock back. |
| Software that remembers the latest date it has seen | Some programs read a clock that goes backwards as tampering - which is exactly what happens when you restore the real date. |
The further the date, the more of this you meet. A machine set to 2038 sees every certificate issued today as expired. Testing for 2038 without that →
It also takes a right most accounts do not have: changing the system time is an administrator privilege, and on a managed machine it is often not yours to use.
When changing the clock is the right answer
A virtual machine that nobody else uses, with its own clock synchronisation switched off, is a perfectly good test bench. You throw it away afterwards, so nothing it recorded matters. If you have one and the test is a single date, it is the simplest thing that works.
The trouble starts when the machine is the one you work on, the one on the domain, or the one that is also running something that must not notice.
Move one program's clock instead
The shifted time is visible to one process and the children it starts. Your domain logon, your certificates and Windows Update never see it, so nothing in the table above moves - and there is nothing to put back afterwards.
# The application sees 31 December 2027, 23:59:50. Everything else keeps the real date. chrono run "C:\apps\test.exe" --at 2027-12-31T23:59:50 # Start ten minutes before midnight and run at 60 times speed - the year rolls over in ten seconds chrono run "C:\apps\test.exe" --at 2027-12-31T23:50:00 --mode x60
Whether a date moved for one program actually reached it is not something to assume. Every session ends with a verdict and the list of time channels the program really read. How you know it worked →
What this does not replace
- A program that asks a server for the time is outside what a local substitution can reach. The session says so when it sees the program open a network connection, rather than leaving you to assume the test passed.
- Testing the system itself - a service that reacts to the real clock changing, a scheduled task, how Windows behaves around a clock change - has no substitute for changing the clock, on a machine you can afford to.