🐛 Fix: allday events not displaying if start-end date is start of week #440
Conversation
This helps with cases where the incoming date filter is malformed or invalid. One common case is where a timezone string is sent over HTTP. The timezone string contains a "+" character which is a special character and is replaced with a space, this character needs to be encoded before sent over HTTP. If we receive a non-encoded timezone date string, we need to catch it here, or we would have issues with filtering.
Since we now validate incoming dates in the `getReadAllFilter`, this change thankfully caught a failing test, test is now fixed.
Updated the event API to encode the start and end date parameters in the request URL, ensuring proper handling of special characters and preventing potential issues with malformed date strings.
Updated the event preparation logic to convert start and end dates of all-day events to ISO 8601 format using toUTCOffset, since events are not always ISO8601
…onversion to ISO 8601 This script migrates all-day event start and end dates in the database to ISO 8601 format, addressing inconsistencies caused by mixed date formats. It includes logging utilities and handles timezone detection based on existing timed events.
Modified start and end dates for all-day events across multiple mock files to ensure they conform to ISO 8601 format. This change addresses inconsistencies in date handling
|
What about the sync code? Since we're now diverging from the way gcal tracks all-day events of This wouuld affect the mappers as well. Overall, I'm concerned that there are some downstream bugs that'll arise from this in it's current state |
I didn't get the opportunity to read the sync code yet, I am assuming we also need to explicitly handle how compass retrieves all day events from google calendar there as well. I'm not sure the level of changes required to make this work, but since you are more familiar on how the sync code works, I will make the assumption that the changes are not small. If that's the case, I'll continue researching and experimenting with different solutions that don't involve changing the DB model. |
|
Ok. If you don't find an easy fix that you can do on the frontend, let's leave the bug until we get a backend engineer. Changing the frontend, DB model, and backend all in one PR without accounting for all the downstream affects is a recipe for pain. |
…ts when filtering See #440
|
Closing after deciding to tackle problem in a different way (see #428 ) |
Description
Closes #428
Any all day event that is created at the start of the week (regardless of whether it was created on 2025-05-18 or not) is not displayed upon refreshing page.
Context
We fire a single API request that returns both grid events and allday events in one go.
The API request that is fired sends a
startandendparameters to specify the date range for the returned events. These parameters are an ISO 8601 date strings.Timed events are stored as ISO 8601 date strings.
While all-day events are stored as raw date strings (
YYYY-MM-DD)Problem
If we have the following scenario:
startandendparameters fired would be2025-02-02T00:00:00+03:00and2025-02-08T23:59:59+03:00(remember, we send them as ISO 8601 strings)2025-02-02T00:00:00+03:002025-02-02The result would be:
2025-02-02T00:00:00+03:00can be lexicographically compared to the provided ISO 8601 date string2025-02-02cannot lexicographically compared to the provided ISO 8601 date string.Solution
We need to run
migrate-allday-eventson staging and prod once for each env after merging this PR.