Creating a shift over daylight savings change causes shift to be shortened and to display incorrectly in web UI

[kandaker]

What went wrong?

What happened:
Our app Oncall Scheduler (oncallscheduler.com) syncs oncall schedules into Grafana Oncall. A joint customer which uses both tools together just let us know that the sync into Grafana Oncall causes a gap in the schedule, at the end of the shift which crosses the spring daylight savings change on 3/2. In researching this we have produced an isolated repro of what looks like two daylight savings change bugs in Grafana Oncall.

Creating a shift and schedule from scratch through the Grafana Oncall REST API, we do steps 1-4 in the repro steps below. This creates a shifts which starts on 3/1 before the daylight savings change, and ends on 3/2 after the daylight savings change has occurred.

What did you expect to happen:
Because of the "duration" parameter when creating a shift, rather than an "end date/time", there are two Grafana Oncall behaviors which could make equal sense. We see one of these expressed in the data we get from the REST API when doing a GET, but the behavior in the web UI (and probably the alert routing engine) don't match either of those two reasonable behaviors.

Expected option 1: for Grafana Oncall to honor the duration parameter and not do anything to adjust for the daylight savings change event.
This matches what we get back in the REST API. The duration remains 86400 seconds, which is what was written with a POST before.
But this is not what the web UI shows.

Expected option 2: for Grafana Oncall to try to help with the daylight change event by shortening the duration by 1hr (= 3600 secs), making it 82800.
This is not what we see in the REST API, and also not what the web UI shows.

What we see in the web UI has two unexpected behaviors:

1. The shift start and end times shown in "User's local time" UTC are 3/8 17:30 (as expect) until 3/9 15:30 (which is not what's expected. With option 1 it should be 17:30, and with option 2 it should be 16:30). That is 2 hours off from what we expect with option 1, and 1 hour off from what we would expect with option 2. It's as if the intended design is option 2, but something causes the daylight savings change adjustment to happen twice.
2. This 2nd issue is completely unrelated to the issue above, and a UI-only issue: The "Current timezone" shown and used to show the shift start and end times (next to showing them in the "User's local time" of UTC) is "(GMT-8)", although at the time when the end time comes to pass, the "current time zone" will be "(GMT-7)". That's pretty confusing. The shift is displayed as being 3/8 9:30 until 3/9 7:30 in Pacific time (using PST). But if you look at that shift on the morning of the shift (when the current time zone will be PDT), I'm assuming the display will change to show 3/8 10:30-3/9 8:30. With either display though, the issue caused by Add basic project governance #1 above also impacts the times displayed.

The most serious impact of this bug is not that the web UI shows incorrect times, but we assume that the alert routing engine will follow the same logic, and thus unexpectedly leave 2 hours during which alerts won't be routed as the customer intended.

How do we reproduce it?

1. POST to "on_call_shifts/"
   {"name":"Test rotation name from Backup2Users","type":"single_event","start":"2025-03-08T09:30:00","duration":86400,"users":["UV8YPE5CTQDW6"]}

• response CREATED
  {"id":"OH3I6I7DGJJWU","team_id":null,"schedule":null,"name":"Test rotation name from Backup2Users","type":"single_event","time_zone":null,"level":0,"start":"2025-03-08T09:30:00","duration":86400,"rotation_start":"2025-03-08T09:30:00","users":["UV8YPE5CTQDW6"]}

2. POST to "schedules/"
   {"name":"Test run schedule - Primary","type":"calendar","time_zone":"America/Los_Angeles","shifts":["OH3I6I7DGJJWU"]}

• response CREATED
  {"id":"SSL4QISFCZ1XG","team_id":null,"name":"Test run schedule - Primary","time_zone":"America/Los_Angeles","on_call_now":[],"shifts":["OH3I6I7DGJJWU"],"ical_url_overrides":null,"enable_web_overrides":false,"slack":{"channel_id":null,"user_group_id":null},"type":"calendar"}

3. GET to "schedules/SSL4QISFCZ1XG"

• response OK
  {"id":"SSL4QISFCZ1XG","team_id":null,"name":"Test run schedule - Primary","time_zone":"America/Los_Angeles","on_call_now":[],"shifts":["OH3I6I7DGJJWU"],"ical_url_overrides":null,"enable_web_overrides":false,"slack":{"channel_id":null,"user_group_id":null},"type":"calendar"}

4. GET to "on_call_shifts?schedule_id=SSL4QISFCZ1XG"

• response OK
  {"count":1,"next":null,"previous":null,"results":[{"id":"OH3I6I7DGJJWU","team_id":null,"schedule":"SSL4QISFCZ1XG","name":"Test rotation name from Backup2Users","type":"single_event","time_zone":null,"level":0,"start":"2025-03-08T09:30:00","duration":86400,"rotation_start":"2025-03-08T09:30:00","users":["UV8YPE5CTQDW6"]}],"page_size":50,"current_page_number":1,"total_pages":1}

Go to the Grafana Oncall schedule web page to see the incorrect start and end times for the shift.

Grafana OnCall Version

The Grafana Oncall version running in Grafana Cloud on 2/15/2025.

Product Area

Schedules

Grafana OnCall Platform?

I use Grafana Cloud

User's Browser?

No response

Anything else to add?

No response