[Google Calendar]- Get Events filter by start and end date are mixed up

[jolo-dev]

Describe the bug The Google Calendar- node Get All- operations results empty when Option Start time < End time is set.

To Reproduce Steps to reproduce the behavior:

1. Add Google Calendar
2. Connect via OAuth
3. Choose Resource: Event, Operation: Get All, Calendar ID: your-id, Return All
4. Click on Add Option and choose Start Date < End Date
5. Now choose Start Date > End Date

Expected behavior The result shouldn't be empty when Start Date < End Date (imo)

Environment (please complete the following information):

• OS: MacOS Monterey 12.3
• n8n Version: 0.170.0
• Database system: Postgres
• Operation mode: own

[Joffcom]

Hey @jolo-dev,

I was talking about this one the other day with someone, Technically the fields are not mixed up although it does feel that way and often works out that way.

The API Google provide for working with their Calendar service uses 2 values timeMin and timeMax

timeMax
datetime
Upper bound (exclusive) for an event's start time to filter  by. Optional. The default is not to filter by start time. Must be an  RFC3339 timestamp with mandatory time zone offset, for example,  2011-06-03T10:00:00-07:00, 2011-06-03T10:00:00Z. Milliseconds may be  provided but are ignored. If timeMin is set, timeMax must be greater than timeMin.
---
timeMin
datetime
Lower bound (exclusive) for an event's end time to filter by.  Optional. The default is not to filter by end time. Must be an RFC3339  timestamp with mandatory time zone offset, for example,  2011-06-03T10:00:00-07:00, 2011-06-03T10:00:00Z. Milliseconds may be  provided but are ignored. If timeMax is set, timeMin must be smaller than timeMax.

To use this the Start Time is timeMax and the End time is timeMin which to me seems really confusing but we have used the same labels in our interface as well. I am not sure if anyone has found any cases where it doesn't work swapping the values around but it always seemed odd to me that Google had them setup this way to begin with.

What this does mean though is this is not really a bug and it is more of a feature request which we track over on our community support forum, What I will do though is add this to our internal tracker as it is a bit annoying.

[jolo-dev]

@Joffcom thanks for the reply. Hmm interesting. I am playing around with the API and must say the Api in general is quite difficult to understand 😅

[jolo-dev]

@Joffcom Now I re-read the official API and I am not a native English but it says

Upper bound (exclusive) for an event's start time to filter by. which means get me all the events which have startDate until the given date. Since we are talking in a range context, I would say this would be the End Date.

Lower bound (exclusive) for an event's end time to filter by. which means get me all the events which have endDate since the given date. Since we are talking in a range context, I would say this would be the Start Date.

Furthermore, it also says If timeMin is set, timeMax must be greater than timeMin. and If timeMax is set, timeMin must be smaller than timeMax. which is confusing if we use your wording If endDate is set, startDate must be greater than endDate and If startDate is set, endDate must be small than startDate.

What do you think?

[dogik]

I have to agree with @jolo-dev on this one. I was very surprised that I had to do it vice-versa. Very unintuitive. I had to spend 30 minutes to figure it out.

[Joffcom]

Hey @dogik,

Oh no doubt there, it confused me as well. We are in the process of making changes to existing nodes to make them easier to use and hopefully this idea will be part of that.

[jhofker]

Gotta say, this really messed me up too 🥲 I had to track it down in the event description code just to make sure I wasn't going crazy

Could be useful to add a note into the interface with this!

[edutrul]

Yeah, you are right, it is basically the opposite. I am attaching screenshot as this can help somebody.

[Joffcom]

Morning,

I put in a PR yesterday which will finally sort this one out 👍

[Joffcom]

The PR has just been merged so should be good in the next release. We have renamed the fields as well to Before and After with new descriptions.

PR is here https://github.com/n8n-io/n8n/pull/5529 if anyone wants to play with it early but I suspect we will be doing a release either today or tomorrow.

[janober]

Fix got released with [email protected]

[edutrul]

Thank you!

[Joffcom]

Hey @edutrul,

Have you had a chance to play with it yet?

[edutrul]

Thank you, @Joffcom

This is working as expected