I really oughtta go back to my corner because I'm not super smart on creating the most efficient or neatest rules, but I have a feeling your latest build there is going to be problematic (I may be wrong!)...
My approach to Rules is to KISS as much as possible, so if it helps to break an idea down into 2 or more rules (instead of trying to make it work in one rule), that's almost always OK to do.
A Trigger is well, a trigger - I try to keep those as simple, clear, and black-&-white as possible so there's no absolutely question about when it occurs. I myself would not use an "X or Y" trigger - to me, it risks unnecessary confusion (both to me and the hub!)
A Predicate condition is like a sleep/wake gate for the rule - this may be an oversimplification, but I think of it this way... When the trigger event happens, it checks the rule for a predicate -- if the predicate is true, then the rule fires; if the predicate is false, the rule doesn't fire. The predicate determines if the rule is live / in play or dormant when its trigger triggers.
A Predicate is not required to use for every rule, but it can be a powerful and easy way to help regulate a desired action.
As I said in a prev post, I'd try making the Jan-Oct date range the Predicate condition, and then use SS-120 as the trigger to turn on the outlets.
In that same rule, you can add a "Wait for" condition to wait until SR+120, then turn the outlets off.
Or you could skip that whole Wait condition in first rule and instead create a second rule that has a Predicate of those outlets being on, a trigger of SR+120, and an action to turn off those outlets.
Either option should be fine - as I understand it, there's no meaningful performance-related penalty to splitting it up into 2 rules vs just one, but someone smarter than me can hopefully confirm or elaborate on that.