Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#834 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@AShatsila ci sta già lavorando.

Dal 26/9/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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 (#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.

Image Image Image
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 (#670) and the back end (#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.
Lingua principale
Python
Stelle
10
Fork
33
Merge medio
2g 4h
PR unite (30g)
10

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openedx/openedx-core

Tutte le issue di openedx/openedx-core

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.