I read Help docs as I always do. I found no helpful insights on what to do, which is the reason why I posted here, under Questions & Suggestions. Since you're the developer, I thought you might provide some clues as to what's wrong. The basic conditions for the macro to operate as it's intended are satisfied.
I confirmed it works in KM version 5 on an older device. The Engine log also detects the trigger, like so
2023-03-25 15:50:12 Execute macro ‘Quit Mail’ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:17 Execute macro ‘Quit Mail’ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:22 Execute macro ‘Quit Mail’ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:27 Execute macro ‘Quit Mail’ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:32 Execute macro ‘Quit Mail’ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:37 Execute macro ‘Quit Mail’ from trigger Every 5 seconds between 15:00-16:00 every day
2023-03-25 15:50:42 Execute macro ‘Quit Mail’ from trigger Every 5 seconds between 15:00-16:00 every day
It turns out the culprit is not that the engine is sleeping but that it's in the GUI level. In the version of KM that the issue manifested in, the time range incrementors (and other numerical incrementors, for that matter) respond incorrectly to the input from the keyboard when I'm entering the numbers. The numbers I type are offset by 3 units, so when I key in "20" the incrementor field shows "23". It appears, the latter is the value the engine accepts actually. The mismatch caused the entered span for the action to kick in to fall on deaf ears: the engine was getting different instructions than I told it, so it was always missing the interval.
To set desired values only worked with the keyboard arrow keys or the incrementor arrows.
I still have it in KM 10.2. The macro was working for 3 days then stopped. I attach 2 log files: the Engine.log messages reporting about the "Quit Mail" macro and the one I made of KM entries in the Console messages I collected by entering the keyword "com.stairways".
The very first message from the latter caught my attention
User Defaults 01:28:09.556470 +0300 97825 1 debug com.apple.defaults CoreFoundation Keyboard Maestro Engine found no value for key NSPersistentUIShowQuietSafeQuitStatus in CFPrefsSearchListSource<0x6000020e4580> (Domain: com.stairways.keyboardmaestro.engine, Container: (null))
as did those from the Engine.log
2023-03-31 01:33:47 Running application query took a while (4235 us)
2023-03-31 01:33:47 Running application query took a while (4804 us)
2023-03-31 01:33:55 Running application query took a while (27307 us)
2023-03-31 01:33:55 Running application query took a while (3028 us)
I may be onto something in identifying the cause of the intended behaviour failure.
This trigger (and, perhaps, other time-induced KM triggers) appears to not be able to discern the lapse happening during the transition from one day to the following day. Particularly, this peculiarity becomes apparent when time ranges are involved. If both extremums fall within the same day the trigger fires up. If they don't the trigger blanks out.
My impression is that it translates the time units to scalar values and applies computations accordingly, completely ignoring the PM and AM qualifiers so that when it encounters a time range simllar to what's in the picture above it discards the day-to-day transition and thinks that 23 > 4. Being incapable of taking into account the aspects of the revolving nature of day change, the trigger sees it as an error and exits.
In the example below, it's the exact cause of why the macro was persistently going down. The solution exists but it's a bit clumsy and not intuitive: it's to create 2 ranges and tell the trigger to respect both (see the picture).
@peternlewis, its it possible to mend the logic to bring it into accord with the human perception of the daytime rather than strictly mathematical perception?
But its appreciation of time not without limitations since it knows it not well enough to figure out that 23:00 – 04:00 is a continuous flow. When it comes to practice, at least.
So it does consider the interval from 23:00 to 00:00 to be a valid one? That's what you meant to say? 00:00 is the next day.
I'm afraid I failed to understand you the way you expressed the underlining message. "Tomorrow, it's never tomorrow". It is, for me, and I expect software to serve my purpose not its purpose. Could you re-phrase this sentence?
00:00 is the next day and is the point on the timescale that you admitted KM recognizes. So, it recognizes 00:00 but not 01:00 and what comes after.
There's nothing ambiguous about "23:00 - 04:00". Remember, quote-unquote, Keyboard Maestro knows that 04:00 comes after 23:00
There is something ambiguous about 23:00-04:00 every Tuesday.
Without an unambiguous answer to what that means I can't implement it.
Regardless, whether I change the behaviour or (more likely) not, the solution is to use two triggers today. Changing the behaviour (which I probably wont do for the reasons I've already outlined) wont help today (or tomorrow or the next day). Using two triggers will.
Computers still aren't as good at inference as you are.
I completely understand the urge to use natural language to set the time period you want -- but KM would likely still split that into two schedules behind the scenes (do some searching on cron evaluation for why). So perhaps it's better to have that split shown from the get-go, removing any ambiguity for both the user and the computer.