Don't send expired overrides in watch context

[elnjensen]

I'm not 100% pleased with this solution since we create the temporaryOverride struct first, only to possibly set it to nil after that. But a cleaner solution has evaded me - it is complicated by the fact that either an undefined end date (indicating an indefinite override) or a defined end date that is in the future are both things that we want to keep. The alternative would be a more complicated if-then block to check the end of the override, and then create, or not, the override struct. As written here, the creation of the struct handles the optional checking for the end of the override and defines a value there, and then we can do a simpler if-then check to decide whether or not to discard it.

[bharat]

I took a quick look at it. Would something like this work?

                    let endDate = override.end ?? .distantFuture
                    if endDate > Date() {
                        context.temporaryOverride = WatchDatedRange(
                            startDate: override.start,
                            endDate: endDate,
                            minValue: override.value.minValue,
                            maxValue: override.value.maxValue
                        )
                    }

[elnjensen]

Perfect. Don't know why I didn't see that. Still getting used to the different ways of dealing with optionals in Swift.