出于测试原因，我希望能够调整 Quartz.Net 当前认为的时间，因此我不必等待数小时、数天或数周来检查我的代码是否正常工作。
为此，我创建了以下简单函数（它在 F# 中，但可以用 C# 或其他语言轻松完成）：
let SimulateTime = fun () ->
currentTime <- DateTimeOffset.UtcNow
timeDifferenceInSeconds <- (currentTime - lastCheckedTime).TotalSeconds
simulatedTime <- simulatedTime.AddSeconds((timeDifferenceInSeconds *scaleTimeBy))
lastCheckedTime <- currentTime
simulatedTime
currentTime、lastCheckedTime 和simulatedTime 都属于DateTimeOffset 类型，而timeDifferenceInSeconds 和scaleTimeBy 都是float 类型。
然后我将 SystemTime.Now 和 SystemTime.UtcNow 更改为使用上述函数，如下所示：
SystemTime.Now <-
Func<DateTimeOffset>(
fun () -> SimulateTime())
SystemTime.UtcNow <-
Func<DateTimeOffset>(
fun () -> SimulateTime())
Mark Seemann 在我的上一个问题中展示了这一点，可以在这里找到。
现在这主要是有效的，只是似乎较长的功能导致它偏离了相当大的幅度。我的意思是我所有的触发器都会失火。例如，如果我将触发器设置为每小时发生一次，并将 scaleTimeBy 设置为 60.0，以便通过的每一秒都计为一分钟，那么它永远不会真正按时触发。如果我有一个失火策略，那么触发器可以关闭，但它列出的激活时间将迟到半小时（因此比本示例中应该慢了整整 30 秒）。
但是我可以这样做：
Console.WriteLine(SimulateTime())
Thread.Sleep(TimeSpan.FromSeconds(60.0))
Console.WriteLine(SimulateTime())
在这个例子中，两次输出到屏幕上的时间差正好是一个小时，所以调用似乎不应该比它增加那么多的时间差。
有人对如何解决此问题或处理此问题的更好方法有任何建议吗？
编辑：所以 SimulateTime 函数的 C# 版本将是这样的：
public DateTimeOffset SimulateTime() {
currentTime = DateTimeOffset.UtcNow;
double timeDifference = (currentTime - lastCheckedTime).TotalSeconds;
simulatedTime = simulatedTime.AddSeconds(timeDifference * scaleTimeBy);
lastCheckedTime = currentTime
return simulatedTime;}
如果这可以帮助任何人解决这个问题。