Switching modes and time systems doesn't assert the default bounds of the new time system

[mudinthewater]

Issue mentioned as part of: #252

Describe the defect

When switching between modes or time systems, unexpected time ranges are applied to the incoming mode. These range from benign (Switching from realtime to recorded asserts the same window as the realtime window, for example) to absurd - switching from sclk to scet can result in a time in 1969.

Expected behavior

I am torn on the realtime->recorded behavior. In some respects, switching from realtime to recorded should show you exactly what you were just on. But a more natural workflow would be that switching from realtime to recorded either:

1. shows you the default recorded bounds
2. shows you the last range that the fixed timespan had

I'm somewhat not convinced that my users will want to switch to recorded to see the exact same range they just left in realtime mode, but this one is subjective.

The bigger problem is that the default bounds of time systems don't seem to be applied when switching from time system to time system. So switching ERT to SCET causes issues or scet to sclk, etc etc. I think when switching time systems the most natural thing would be that the new time system has its default bounds asserted. Thoughts @davetsay or @jvigliotta?

Steps To Reproduce
1.

Additional context