[Feature request] Allow temporarily allowing for a duration, rather than a fixed end time

[thislooksfun]

I am often finding myself wanting to allow a particular app for a short period of time while I am actively using it across multiple invocations (e.g. allowing curl to connect to anywhere while I am running a script that calls it multiple times). Currently the only way to do this is to either do a blanket allow and revoke it later, or allow it until a particular time. The issue I have though is that the way of inputting how long to allow for is a bit clunky. I would love a way to say "allow this app for the next X seconds/minutes/hours". That behavior is currently possible, but only if I:

1. Figure out the current time
2. Convert that to 24hr time (not the default here)
3. Add on however much time I want, remembering to wrap for midnight if I'm working late
4. Enter that time

This process works, but it's much slower than just selecting "allow for 30 minutes" and having the computer do the math for me.

[objective-see]

Good point, I think I originally went the "enter clock time" (vs. duration), as then LuLu wouldn't have to do that "clunky" logic (wraps, etc) ...cuz under the hood I think LuLu has to store it as "clock time" since if there is a reboot before the expiration, it'd otherwise loose the delta (e.g. if you entered 1 hr, then the system was restarted after 30min, when LuLu re-starts it wouldn't know how much longer to wait...

Let me ponder on this, cuz I'm wondering if I change this, others will want the "clock time" back

[thislooksfun]

I may be biased, but I think that if we have to choose one or the other it is much more useful to have the relative time than the absolute time. That being said, I think that if you do have the relative time format then supporting both isn't actually that much extra work. I would implement the relative time version using the absolute time system. That is,

1. User enters "15 minutes" (not sure what the UI would look like, but that's a separate discussion)
2. LuLu determines the current time
3. You then add the two together to get the end time
4. Store that end time as you do now

As you can see, step 4 uses the same "enter the end time" system that is present now, just with the overgrown calculator (the computer) being the one doing the math for steps 1-3.

Additionally, I don't know how LuLu stores the end time under the hood, but assuming it is using Unix timestamps this should be pretty easy. Since the times entered are guaranteed to be relative (i.e. "15 minutes from now") and virtually always going to be small (and I would be alright with enforcing a max of say a day to keep the bounds simple), you don't really have to worry about things like timezones or daylight savings, so steps 1-3 above can be as simple as:

1. Convert the entered duration to seconds
2. Determine the current unix timestamp
3. Add the two together

[objective-see]

Ok, I've changed this, do you can now input rule duration, as a relative time.

[thislooksfun]

Thank you! That looks perfect!