Issue 83 Validating Booking API

[IIEnat]

Change Summary

Modified the validate() function for the booking api such that collisions are no longer possible.

Change Form

Doesnt use the exdate / rdate stuff
also i borrowed a helper function from eden

• [ x ] The pull request title has an issue number
• [ x ] The change works by "Smoke testing" or quick testing
• The change has tests
• The change has documentation

Other Information

I placed a hard coded upper bound for the window range which is 1 year. This means that if a collision were to happen only after a year, the filter would miss it. lmk if this is a bad idea.

Related issue

• Resolve Add logic in booking to validate if the room is available #83

[EdenWuyt]

Hi Enat! Dont know if it will affect your code but I just wanna share with you that the rrule may need stronger validation based on my current implementation. When I try something like UNTIL=20250130, the backend crashes and it shows that "ValueError: RRULE UNTIL values must be specified in UTC when DTSTART is timezone-aware". So it has to be something like UNTIL=20250130000000Z in UTC timezone. I find it quite interesting and also something worth noting.

[IIEnat]

Hey Eden, thanks for pointing that out. I looked into it and the crash is raised by python-dateutil when parsing the RRULE (not directly by Google Calendar). Specifically, it happens at this line from the _expand_recurrences function
rrule_set.rrule(rrulestr(rrule_str, dtstart=start_local))

When DTSTART is timezone-aware (which it is in our case), dateutil requires UNTIL to be specified as a UTC datetime (YYYYMMDDTHHMMSSZ). A date-only value like UNTIL=20250130 is treated as “floating” and triggers the ValueError you saw.

Worth noting: this same behaviour is also present in the room availability since it uses the same function (in PR #90). A room rule with UNTIL=YYYYMMDDTHHMMSSZ works fine, but UNTIL=YYYYMMDD raises the same error when it gets parsed.

I think the cleanest approach is to standardise on storing UNTIL in YYYYMMDDTHHMMSSZ and either:

• normalise UNTIL=YYYYMMDD → UNTIL=YYYYMMDDT235959Z before parsing/storing, or
• reject date-only UNTIL and require the frontend to always send the UTC format.

Additionally, as I am not so familiar with google calendar recurrence rules please let me know if it is also beneficial to allow/store the YYYYMMDD form too, or should we just enforce/normalise to the UTC datetime format everywhere?

[EdenWuyt]

I agree with you that the cleanest approach is to enforce the UTC datetime format in UNTIL! I am also not familiar with Google Calendar and RRULE, so I asked AI and it mentioned that UNTIL in a date format may be needed when DTSTART is also date-only (else dateutil.rrule will break). Yet I don't think it applies to our booking system as the start datetime is always a timezone-aware datetime object (by setting USE_TZ = True in settings.py). So I suppose it will be safe and consistent to allow only UNTIL with a UTC format stored. Maybe we can add it in the README to let the front-end folks know so that they can send the data in the correct format?