-
Notifications
You must be signed in to change notification settings - Fork 242
Description
Is your feature request related to a problem? Please describe.
I’d like to clarify how MDS should compute the duration of dwell time. Given a “time-type” policy like so:
{
"name": "Greater LA limit dwell time limit for non-op and reserved",
"rule_id": "a7eb28b9-969e-4c52-b18c-4243a96f7143",
"rule_type": "time",
"rule_units": "hours",
"geographies": [
"12b3fcf5-22af-4b0d-a169-ac7ac903d3b9"
],
"states": {
"non_operational": [],
"reserved": []
},
"vehicle_types": [
"bicycle",
"scooter"
],
"maximum": 24
}
My understanding is that a scooter in the ...3b9 geography would match under the following conditions:
- 24 hours or more continuously in a non_operational state.
- 24 hours or more continuously in a reserved state.
- 12 hours in a reserved state, followed by 12 hours or more in a non_operational state (uninterrupted by any other state changes).
Describe the solution you'd like
I want to confirm the following (and add some wording for clarity to the spec): The timer does NOT reset if there is a state change where both states are listed in the rule, and the vehicle has not exited the geography.
Is this a breaking change
A breaking change would require consumers or implementors of the API to modify their code for it to continue to function (ex: renaming of a required field or the change in data type of an existing field). A non-breaking change would allow existing code to continue to function (ex: addition of an optional field or the creation of a new optional endpoint).
- Possibly breaking: If users have built their compliance evaluator to restart the timer on a state change.
Impacted Spec
For which spec is this feature being requested?
policy
Describe alternatives you've considered
None.