Time Threshold does not have any effect

[Acidham]

When I am setting Time Threshold to 20 minutes, the workflow shows all events in a day and not as expected within the next 20 minutes.

My time format is set to: HH:MM:SS (24hrs)

[caleb531]

@Acidham That should be fine. Although 20 should already be the default value for that Time Threshold field. Also keep in mind that you should not specify any units in the field (i.e. the field is of type integer, strictly). The units are already implied to be minutes.

Can you please send me a screenshot of the values you currently have entered into User Configuration? Here's what mine looks like:

[Acidham]

I did not change the default value.

[caleb531]

@Acidham Hm, that is strange. May I ask what timezone you are in? And also what is your system-set language/locale?

[Acidham]

May I ask what timezone you are in?

❯ python3 -c 'import time;print(time.tzname)'
('CET', 'CEST')

And also what is your system-set language/locale?

❯ python3 -c 'import locale;print(locale.getdefaultlocale())'
('en_US', 'UTF-8')

[caleb531]

@Acidham Sorry for the delay in replying. I've been thinking about this ever since you sent your timezone/locale details above.

I've reviewed the code that does the time computation, and I can't see how the minutes can be interpreted any other way than what is correct. So I suspect the discrepancy is stemming from the data in one of your calendar events (which should always be local time, based on how I'm retrieving them, but maybe not in your case). 🤷‍♂️😅

[Acidham]

I tried to debug your code on my side, but after upgrading to macOS 13.0 the Workflow stopped working. It seems osascript is stuck/running forever.

[caleb531]

@Acidham Oh, sorry to hear that. I have not yet upgraded to macOS Ventura, but I am planning to soon. I'll make a note to debug this workflow when I'm done upgrading (I use it myself, after all).

[caleb531]

@Acidham After further research, I would recommend you run xcode-select --install in the Terminal to see if Apple's Command Line Tools need to be reinstalled:

xcode-select --install

Follow the prompts if it asks you to install the Apple Command Line Tools again. Once everything downloads and installs, that may resolve the post-upgrade issues.

[Acidham]

I already did that for my other workflows. But yours is not working and I am not sure if it is related to Ventura.

when I try to execute the apple script nothing happens and ScriptEditor need Force Quit to stop

[caleb531]

@Acidham Hmm, how many calendars do you have enabled? On average, how many calendar events do you have per day in the Calendar app

One other thing you can try is making sure that Alfred has the appropriate permissions to run the workflow. Not sure if "Terminal" will need the same permissions, but you can probably play around and see if anything works better.

[Acidham]

For sure, Privacy&Security is set up in the right way.

What I found out after debugging your code (event.py, after 5 min wait time) is that all calendars will be loaded also the ones which are not set to active in calendar app (e.g. Family calendars).

Is there to tell the AS which calendar to load?

[caleb531]

@Acidham That should be doable. Will take some work on my part, though. I'll create a separate issue for this, and tag you so you can follow the progress (as I will eventually want you to test the beta version).

[Acidham]

(as I will eventually want you to test the beta version)

coun't me in!

[caleb531]

@Acidham Now that #19 is taken care of, please let me know if this time threshold quirk is still present for you.

[caleb531]

@Acidham Just want to follow up on this: are you still experiencing issues with the time threshold?

[Acidham]

Good that, you ask. The time threshold does not work. The workflow shows all event in the current day and not as expected in the configured time threshold.

[caleb531]

@Acidham Interesting. I still want to get to the root of this issue, and since I am unable to reproduce the issue myself, can you please send me an email and perhaps we can schedule a Zoom call? I think some live-debugging of the workflow code on your end would really help to identity what is going on.

[Acidham]

It is a bit weir'ed .... Any number below 17 min is not working, everything above is working. You may change some numbers below 17 min to reproduce.

[caleb531]

@Acidham Hm, still can't reproduce on my end by changing Time Threshold to some number below 17. But of course, you'll always get the "All Events" view if, say, you change the threshold to 16 minutes, but the meeting is still 17 or more minutes away.

For the event you're testing with, I have three questions:

1. What does the result subtitle say is the start time of that event?
2. What does your system current time say at the moment you answer question (1) above?
3. What is your configured time threshold when testing all this?

The logic for the time range calculation isn't complicated, so I would expect the discrepancy would need to come from some mismatch between the system's current time and the start time of the event.

# Return True if the given date/time object is within the acceptable tolerance
# range (e.g. within the next 15 minutes OR in the last 15 minutes); if not,
# return False
def is_time_within_range(event_datetime, event_time_threshold_mins):
    current_datetime = datetime.now()
    event_time_threshold = timedelta(minutes=event_time_threshold_mins)
    min_datetime = (event_datetime - event_time_threshold)
    max_datetime = (event_datetime + event_time_threshold)
    if min_datetime <= current_datetime <= max_datetime:
        return True
    else:
        return False

[Acidham]

I think I found the issue after debugging. Your logic line 104 is saying elif all_events and not upcoming_events: when upcomming_events (no events found in threshold) use all events.

And shame on me, the workflow result is stating exactly this, "Showing all Calendar Events". But this "feature" was somehow not expected and therefore I was confused.

[caleb531]

@Acidham It's alright! I actually realized a few days ago that the wording isn't clear, and have pushed 0b6cb8a to improve the wording. I may still tweak this wording a bit more to make things even more clear.

All that to say, the language will be clearer in the next release of the workflow.