Change start/end date/time to timeslots #15
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Now it calculates the start/end date/time based on the original event's time zone. It makes more sense this way to represent the full range that the event creator intended.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR refactors the event and availability endpoints to use ISO-formatted timeslot lists instead of separate start/end date/time parameters. The changes improve data flexibility and accuracy by allowing non-contiguous timeslots and better timezone handling.
Key Changes:
- Event creation/editing endpoints now accept a list of datetime timeslots instead of date ranges and time ranges
- Availability data model changed from boolean
is_availableto stringstatusfield, with removal of "unavailable" records - Dashboard endpoint now requires user's timezone as a query parameter for accurate local time display
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 18 comments.
Show a summary per file
| File | Description |
|---|---|
| api/models.py | Added AvailabilityStatus enum and replaced is_available boolean with status field in availability models |
| api/migrations/0020_remove_eventdateavailability_is_available_and_more.py | Migration to remove unavailable records and transition from is_available to status field |
| api/utils.py | Added get_event_type utility function and UserEvent import |
| api/event/views.py | Updated create/edit/details endpoints to use timeslot lists; removed grid-based date/time range logic |
| api/event/utils.py | Replaced daterange/timerange generators with timeslot validation functions; moved get_event_type to api/utils.py |
| api/event/serializers.py | Consolidated serializers to use timeslots field instead of separate date/time range fields |
| api/availability/views.py | Changed from 2D boolean grid to flat timeslot list for availability submission |
| api/availability/utils.py | Simplified get_event_grid to get_timeslots, removing grid dimension logic |
| api/availability/serializers.py | Changed availability field from nested boolean lists to flat datetime list |
| api/dashboard/views.py | Added required time_zone query parameter; uses new format_event_info from dashboard/utils |
| api/dashboard/utils.py | New file with format_event_info function for dashboard-specific event formatting |
| api/docs/utils.py | Added TimeField type mapping for documentation endpoint |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
mirmirmirr
reviewed
Dec 30, 2025
Comment on lines
74
to
79
| user = request.user | ||
| title = request.validated_data.get("title") | ||
| duration = request.validated_data.get("duration") | ||
| start_date = request.validated_data.get("start_date") | ||
| end_date = request.validated_data.get("end_date") | ||
| start_hour = request.validated_data.get("start_hour") | ||
| end_hour = request.validated_data.get("end_hour") | ||
| timeslots = request.validated_data.get("timeslots") | ||
| time_zone = request.validated_data.get("time_zone") | ||
| custom_code = request.validated_data.get("custom_code") |
Member
There was a problem hiding this comment.
I think we should still store date/time event information for the cases when this is needed. This way we can access it without needing to go through min/max calculations.
For example in format_event_info when getting dashboard data on the backend and whenever we need to display event info or populate the editor after fetching event details.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR changes many endpoints to use a list of timeslots instead of "start date", "end date", "start time", "end time". This allows for more flexible data transfer and accurate timekeeping.
Data Format Changes
In all instances where a weekday index is used with an endpoint, that has been changed to a date that is on the corresponding weekday. For example, a "Sunday" date is represented by
2012-01-01.Availability Add Endpoint
Instead of using the horrible grid format, the endpoint now takes a list of timeslots in ISO format. If any timeslots are invalid, an error message will be returned.
Changed Availability Tables
Instead of the
is_availablecolumn, astatuscolumn was added that keeps track of the type of availability (currently only "AVAILABLE", more might come later). There is no longer an "unavailable" timeslot recorded, as that took up unnecessary space.The new migration will remove all "unavailable" timeslot rows. (run
python manage.py migrate)Event Create/Details Endpoints
These endpoints no longer use the start/end date/time as input and output, instead using a list of timeslots to exchange data.
Dashboard Get Endpoint
This endpoint now requires the user's local time zone as a query parameter, so that the data is computed properly for their time zone.
Minor Docs Endpoint Fix
The newly-used
TimeFieldtype wasn't included in the/docs/endpoint, causing an error. That's been fixed.Reorganize Util Functions
A few util functions were in places they didn't need to be, since they were being used (sometimes exclusively) from outside their folder.