Issue with "Calendar Event Query?"

[jst...@gmail.com]

Tried creating a simple task to list all of my calendar events for the day originally using dateFormat on "Now" but was getting the current day's events as well as the next day's.  Tried hard-coding the minimum and maximum timestamps to today 00:00:00 and today 23:59:59 and I'm still getting events for today and the next day.  Are there any known issues with the "Calendar Event Query?" or am I looking at the min/max timestamps wrong?

Thanks,

-Jim

[Henrik Lindqvist]

The min/max timestamps are numbers, not formatted dates. For today's events use:
Minimum: mergeTime(now,0)
Maximum: mergeTime(now,0)+86399.999

[jst...@gmail.com]

Just to clarify, I get that the timestamps are seconds since 1970. Even when I try to use constants for the timestamps with the date picker, I'm still getting events from the next day. I changed my dateParse methods to the mergeTime method you suggested and I'm still getting the same results.

[Henrik Lindqvist]

That shouldn't happen unless the event cross midnight.

Are the calendar and your device using the same time zone?

[jst...@gmail.com]

Yeah they're the same timezone. Not sure if it makes a difference but the events from the next day are all day events. Just tested a discrete event for the next day and that doesn't erroneously show up.

[Henrik Lindqvist]

Thanks for testing.

The issue is that the Android Calendar API uses closed-interval (end-points included) overlap checks, and all-day events range from 00:00 to 00:00.
So a query for the 2nd day will also match 1st day since both include 00:00:00.000 of 2nd day.
It also looks like the code in the Calendar API handling recurring events only use second precision.

There's really no way to work around this, except maybe using...
Minimum mergeTime(now,1)
Maximum: mergeTime(now,0)+86399

[Rob Lund]

Yes! I'm experiencing this exact phenomenon.

All-day event on next day gets found today but reports as GMT.  Very odd.

I tried the mergeTime suggestions below but they didn't filter out these events. Perhaps by doing some sort of check to see if begin and end timestamp is same + 24h and occurs today, then I'll know it's really tomorrow?  Yuck.

[Pete]

Not sure if this would help you all but the work around I use to prevent a similar issue is to check the day of the start time outputted by the Get Event block and if it doesn't equal the current day I skip that event with the following text in an expression block...

dateParts(StartTime)[2] = dateParts(Now)[2]

But in this case you may need to try something like...

dateParts(StartTime+1)[2] = dateParts(Now)[2]

[Rob Lund]

Ahh, nice fix.  That's concise.

On Wed, Aug 23, 2017 at 11:57 PM Pete <pete...@gmail.com> wrote:

Not sure if this would help you all but the work around I use to prevent a similar issue is to check the day of the start time outputted by the Get Event block and if it doesn't equal the current day I skip that event with the following text in an expression block...

dateParts(StartTime)[2] = dateParts(Now)[2]

On Thursday, August 17, 2017 at 1:14:16 PM UTC-6, Rob Lund wrote:

Yes! I'm experiencing this exact phenomenon.

All-day event on next day gets found today but reports as GMT.  Very odd.

I tried the mergeTime suggestions below but they didn't filter out these events. Perhaps by doing some sort of check to see if begin and end timestamp is same + 24h and occurs today, then I'll know it's really tomorrow?  Yuck.

On Wednesday, November 25, 2015 at 10:43:14 PM UTC-7, Henrik "The Developer" Lindqvist wrote:

Thanks for testing.

The issue is that the Android Calendar API uses closed-interval (end-points included) overlap checks, and all-day events range from 00:00 to 00:00.
So a query for the 2nd day will also match 1st day since both include 00:00:00.000 of 2nd day.
It also looks like the code in the Calendar API handling recurring events only use second precision.

There's really no way to work around this, except maybe using...
Minimum mergeTime(now,1)
Maximum: mergeTime(now,0)+86399

On Thursday, November 26, 2015 at 2:10:25 AM UTC+1, jstys92 wrote:

Yeah they're the same timezone.   Not sure if it makes a difference but the events from the next day are all day events.    Just tested a discrete event for the next day and that doesn't erroneously show up.

--
You received this message because you are subscribed to a topic in the Google Groups "Automate" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/automate-user/JfGZl5gLoFY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to automate-use...@googlegroups.com.
To post to this group, send email to automa...@googlegroups.com.
Visit this group at https://groups.google.com/group/automate-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/0634363b-eb9b-4e41-bab5-fad560e22c06%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

ROB LUND // "I solder the body electric"
www.ElectroLund.com  

[Fran T]

That didn't quite work for me. What I had to do was to set a variable in the All day field of the Get Event block, then check the date parts by first converting the all-day time with this:

dateParts(startTime, allDay ? "UTC" : null)[2] = dateParts(Now)[2]

[Fran T]

Thanks to how Google implemented the calendar API, this turns out to be quite a thorny little problem. I wrote a little demo flow to figure things out. I just uploaded it to the community in hopes it'll help others:

http://llamalab.com/automate/community/flows/21077

[Fran T]

Unfortunately Pete's simple trick using dateParts() won't work for multiday events which start before today.

I use this expression in an If block to filter out the offending next-day all-day event:

(!allDay) || (timeMerge(Now, 0) <= localTime(eventStart, "UTC"))

The No path means it's a bad event.

[Fran T]

...and even that code won't property handle multiday events.

What I ended up doing was to first convert the beginning time of all-day events from UTC to local time with this:

localTime(eventStart, "UTC")

Then rejecting future all-day events with this:

eventStart > (timeMerge(Now, 0) + 86399)

From now on, I'll let the code do the talking. Again, see my demo flow here:

http://llamalab.com/automate/community/flows/21077

(Sorry for the spam, but we don't have permission to edit replies!)

[Rob Lund]

Thanks for all your contributions, Fran!