Time ranges for limits sets

[ryan-pratt]

What is the use case or problem this feature would solve?

In flight ops, the relevant limits set is often related to the packet time, rather than the received time. Basic example is SV makes a scheduled maneuver while not in contact with GS. When we receive and process back orbit tlm, packets from during the scheduled maneuver should be evaluated against e.g. the "MANEUVER" limits set instead of whatever the currently selected (or "DEFAULT") limits set is.

Describe the solution you'd like

The ability to set a time range when selecting a limits set. When a packet is received and limits are checked, it should be evaluated against the limits set based on PACKET_TIME.

This could be done either as a new option in the existing menu to change limits sets, or it could be tied to Calendar (Enterprise only). Maybe both? Would be cool to have a Calendar item that's like "set limits set to "FOO" and execute this script."

Additional context

#3434

Screenshots

No response

[crawlchat]

Thanks for this well-detailed feature request! This builds directly on #3434 and articulates the use case really clearly. 👍

Here's a summary of where things stand and some thoughts:

Current State of This Feature

This is not currently supported in COSMOS. The existing limits set mechanism is global — switching limits sets (via UI or set_limits_set("SET_NAME")) applies to all packets regardless of PACKET_TIME. There is no way today to associate a limits set with a time range so that backorbit/stored telemetry is evaluated against the correct set.

Relevant Prior Discussion from #3434

From ryanmelt on #3434:

"Limits checks should always be done for stored, but we should be able to disable limits log messages and limits responses."

And from ryan-pratt in that same thread, the core of the ask is Option 3 — time-range-based limits set applicability via PACKET_TIME.

Possible Implementation Directions

The ideas suggested in this issue are solid:

1. Time-range-based limits set selection — when checking limits, look up which limits set was active at PACKET_TIME (not received time). This would require some kind of "limits set schedule" store.
2. Calendar integration (Enterprise) — a Calendar event that sets the active limits set for a defined time window, which could then be used during limits evaluation by PACKET_TIME.
3. Script-driven — a script that defines time ranges → limits set mappings and calls set_limits_set accordingly during replay.

To help the engineering team scope this properly, a few questions would be useful:

1. What version of COSMOS are you running? (Open Source or Enterprise?)
2. Are you using Calendar already? The Calendar integration idea seems like a natural fit if you're on Enterprise.
3. For the time-range lookup during limits evaluation — would a "best effort" approach work? e.g., "use the limits set that was active at the closest scheduled time to PACKET_TIME", or do you need exact range definitions?