The old SessionInitiator used Durations not Longs for this check. The WallClock has a better clock for measuring durations that won't be affected by funny things like the user changing the time or anything with daylight savings etc. See my comment #5420 (comment)

This is getting the time out of the messages themselves where we don't actually know which clock was used to generate them other than that the framework did. Switching to use our own clock would mean that we'd be keeping track of timestamps based on when the service processes each message as opposed to when the event occurred. It's true that manipulating the system clock might cause a session to be dropped or created when it shouldn't have, but IMO that's a much less important or likely scenario than delays in message delivery.