How to operate VirtualTimeScheduler with NodaTime

[mwpowellhtx]

The prima facie idea of a VirtualTimeScheduler seems interesting. Is it possible to use that using a NodaTime substrate? That is, perhaps leveraging Instant or perhaps Duration, just spit balling there, throwing mud on the wall. Whatever the TAbsolute and TRelative should be, along these lines.

TAbsolute of course being where TAbsolute : IComparable<TAbsolute>, which I think either Duration or Instant would be. Not sure what, if anything, TRelative has to be, presumably as a function of a periodic TAbsolute.

[HowardvanRooijen]

Hi! Glad you find VirtualTime interesting - I'm a firm believer that it's one of Rx's superpowers 👊 - most people use it in test scenarios - and this is covered in the Intro to Rx .NET book here: https://introtorx.com/chapters/testing-reactive-extensions-for-dotnet

BUT we've found really good use cases for using it to run "simulations" where rather than having to wait for real time to process, we can use virtual time to process historic data for "what if" type analysis.

So, what would NodaTime bring to the party that isn't already covered by the existing API?

[mwpowellhtx]

@HowardvanRooijen Any ideas about the above observations? Somewhat turning into a concern over the Timer long observer, thinking I might consider the Timestamp pipeline approach rather than deriving my own custom scheduler.

[mwpowellhtx]

Extending that idea a bit further, this might work, I think. Not sure otherwise how to exactly introduce a static extension method that would operate like the Timestamp pipeline. The main concern is the mysterious s_impl.Timestamp(...) implementation instant, whatever that is doing.

static void OnNodaTimestamp(NodaTimestamped<long> x) { /* ... */ }
var sub = Observable.Timer(DateTimeOffset.Now).Timestamp().Select(x => new NodaTimestamped<long>(x.Value, x.Timestamp.ToInstant())).Subscribe(OnNodaTimestamp);

NodaTimestamped<T> being basically a NodaTime oriented analog of Timestamp<T>.

[mwpowellhtx]

Partially, nevermind, I know it may seem like an absurd question what happens at observability of long.MaxValue. Even if I were to setup a secondly Timer, for instance, not likely to get anywhere near exhaustion.

year seconds	max long		long years
31536000	9.22337203685478E+018	292471208677.536

[HowardvanRooijen]

Sorry, busy few days. I was basically going to say the same. If you're using long to represent time, I believe that long.MaxValue exceeds the allowable value of DateTime.Max. i.e.

DateTime dt = DateTimeOffset.FromUnixTimeSeconds(long.MaxValue).DateTime;

Results in:

System.ArgumentOutOfRangeException: Valid values are between -62135596800 and 253402300799, inclusive. (Parameter 'seconds')

I'd be surprised if your app is still running by then!

[mwpowellhtx]

Well... I would not ever use the Timer observable long to represent time, that does not make any sense. Best I could determine, the long value is a simple step number, iteration count, whatever. However, the code docs are not at all clear what exactly that value represents.

And the further conclusion, I doubt we would ever exhaust long.MaxValue arranging a due time and period Timer. But that being said, an interesting test case might be to set the count number to something approaching long.MaxValue`, and see what happens. That is beyond the scope what I need to accomplish, personally, however.

Best, and thanks for the response.

[mwpowellhtx]

Overall, at present, I think I have what I need to move forward.