[Bug] Start date filter on the Competency Management page uses UTC days, while Studio shows course dates in the user's time zone #834

Parent: #670 (front end). Related: #669 (back end).

Environment: Master Sandbox, https://apps.master.openedx.io/authoring/taxonomy/45/competencies

Summary

The course search on the Competency Management page filters courses by start date. The user picks a calendar day in their own time zone, but the back end compares it against a UTC day. When a course starts late in the evening UTC, or early in the morning UTC, the two days are different, and the filter does not return a course that Studio shows as starting on the selected day.

How the filter works now

1. The date picker sends the selected local calendar day as a plain date, for example start_date_on_or_after=2027-07-01&start_date_on_or_before=2027-07-01.
2. The back end ([BE] Add start-date range filter and outline delivery for accessible courses (Competency Criteria Associations) #669) treats that date as a UTC day: it returns courses whose start is at or after 2027-07-01T00:00:00Z and before 2027-07-02T00:00:00Z.
3. Studio pages, for example the course outline, show the same start date converted to the user's local time zone.

So a user who is not in UTC sees one date on the course page and has to pick a different date in the filter to find that course.

Steps to reproduce (time zones east of UTC, for example Georgia, UTC+4)

1. Open the course outline of course-v1:Axim+DC2+2026_T1 in Studio https://apps.master.openedx.io/authoring/course/course-v1:Axim+DC2+2026_T1. Its start is 2027-06-30T22:00:00Z, so the page shows July 1, 2027.
2. Open https://apps.master.openedx.io/authoring/taxonomy/45/competencies and select any competency.
3. Press "Start Date" and select the range July 1, 2027 to July 1, 2027.
4. Look for "Axim DC2" in the results.
5. Change the range to June 30, 2027 to June 30, 2027.

Expected: The course is found by the July 1 filter, because Studio shows July 1 as its start date.

Actual: The July 1 filter does not return the course. The June 30 filter returns it.

Reproducing from a time zone west of UTC (for example the US)

With the course above, a user in the US does not see the bug: 2027-06-30T22:00:00Z is still June 30 in every US time zone (for example 18:00 EDT or 15:00 PDT), so the local day and the UTC day match. The bug only shows when the local day and the UTC day of the course start differ. Either of these two options makes that happen:

Option A: override the browser time zone. This option reuses the course above and needs no new data.

1. In Chrome, open DevTools, then the three-dot menu, then "More tools", then "Sensors".
2. Under "Location", choose a preset east of UTC (for example "Berlin" or "Mumbai"), or choose "Other" and enter the timezone ID Asia/Tbilisi.
3. Keep DevTools open and reload the page. The override applies only while DevTools is open.
4. Follow the steps in the section above.

Option B: use a course that starts early in the morning UTC.

1. In Studio, create a course (or edit a test course) and open "Schedule & details".
2. Set the course start date to July 1, 2027 and the start time to 02:00. Studio enters the start time in UTC, so the stored start is 2027-07-01T02:00:00Z. In the US that is June 30 (22:00 EDT or 19:00 PDT), and the course outline shows June 30.
3. On the Competency Management page, filter by June 30, 2027 to June 30, 2027. The course is not found.
4. Filter by July 1, 2027 to July 1, 2027. The course is found, although Studio shows June 30 as its start date.

Notes

• The bug sits between the front end ([FE] Competency Management Course Search/View #670) and the back end ([BE] Add start-date range filter and outline delivery for accessible courses (Competency Criteria Associations) #669). The front end sends a local calendar day without time zone information, and the back end has no way to know the user's time zone. The back end parameter accepts only YYYY-MM-DD, so the front end cannot currently send exact local day boundaries as timestamps.
• Possible fixes, for the developer to choose: let the back end accept ISO datetimes so the front end can send the local start and end of the selected days; add a time zone parameter to the request.