A RunAsDate alternative, with the parts that were missing

It is not the channel count. It is that RunAsDate tells you, honestly, in its own documentation, that it "will not affect applications that take the current date/time from another source" - and then leaves you to work out whether yours is one of them.

Chrono Mock treats that same sentence as something to measure. Every session ends with a verdict, the channels the application actually read with a count for each, the channels that were missed, and a warning when the application was seen opening a network connection before it ever asked the clock.

An application that looks time-shifted but is not is worse than one that never launched - it produces a passing test that means nothing. How the audit works →

RunAsDate intercepts GetSystemTime, GetLocalTime, GetSystemTimeAsFileTime, NtQuerySystemTime and GetSystemTimePreciseAsFileTime. For a great many applications that is genuinely enough, because that is where the wall clock is read.

The rest of the surface is where date-dependent code tends to hide:

• the time zone - the two functions that report it, plus the six that convert between zones, which is how a report lands on the wrong day
• the elapsed-time axis - tick counts and unbiased interrupt time, which is what a trial countdown usually measures
• sleeps, so a delay is a delay on the session clock and not on the real one, and object waits, which are counted and keep their real length
• timers - waitable, window, thread-pool and multimedia
• process creation, so an installer's children run in the same session rather than in the present day
• network connections, counted as a sign that the time may come from a server

Of the 44, 30 are put on the session clock. The other 14 are counted and left real, so the report lists them without claiming they were shifted. The wall clock and the time zone are shifted in every session. The elapsed-time axis and the waits are watched when you ask for them with --scale-duration, and the high-resolution counter with --scale-qpc.

Genuinely, and not rarely:

• You need one date, at normal speed, right now. RunAsDate is a download of under 60 KB, has no window to learn and has been doing exactly this for many years.
• You are on an older Windows. RunAsDate goes back to Windows 2000. This tool targets Windows 10 and 11 and is not tested anywhere older.
• Size matters. A 47 KB download against ~2.4 MB for the command line, or ~70 MB with the window, is not a close comparison.
• You do not want a verdict. Measuring coverage means reading the result. If the test is throwaway, that is overhead you did not ask for.
• The application is already running. RunAsDate can attach to a running process since version 1.40. Chrono Mock starts the application itself, so one that cannot be restarted is out of its reach.
• You want several applications at different dates at once. RunAsDate gives each its own date. Chrono Mock runs one session at a time.

The two also coexist. Nothing here stops you keeping RunAsDate for the quick case.

Both tools turn up in searches about extending trial periods. This one is not built for that, and no example, preset or page here will ever demonstrate it. Chrono Mock is for testing software you are responsible for - your own licence expiry, your own renewal logic, your own month-end report.

It is also the case least likely to work. Licence protection routinely reads time through routes chosen to be hard to intercept - the shared user-mode data page, direct system calls, a server - and a clock moving backwards is a condition such code is written to detect. The audit will tell you that it did not work, which is the honest answer rather than a useful one.