Daylight Savings applied to Automation Rule Schedule

Can Docebo just make daylight savings go away for everyone in the world?

var t;

function fixTime(problem) {
  t = new Date();
  t = t.toLocaleTimeString();
  t.remove(problem);
}

fixTime(daylightSavings);

Ah time. I hate time…

@candace.forbes Could this impact Outlook calendar invites? We are seeing the sessions scheduled for after DSL are not updating to the correct time on Outlook calendars. 

How are your invites working, ICS attachments or through Docebo Connect?

@Bfarkas ICS attachments at the moment. 

@jordandb We’re having this same issue with Outlook invites. Did you find a solution yet?

Can you attach a ics example that has the issue?

Sure thing. I had to zip the ics file to add it here because it won’t let me add an .ics file.

I’ve also included an image of the session in Docebo. 

Not yet, we are still researching the issue. 

Wait - so all events need to be fixed when daylight savings starts and ends (if people created January’s events in August for example)?

This is fine for now but going to be a big time issue in March. 

In 2024, we are still seeing this issue... so I re-saved all automation rules to get them back in line...Docebo should look at getting this done automatically instead of us having to remember to do this.

OK I have a notification issue that may be partially caused by this.

My head is exploding trying to articulate this and apologies for any others I may be consigning to the same fate in reading this.

Enrollment Date: March 3 2024 @ 3:11 PM
Notification rule : 11 days after the event @ 2:00 AM

Given the stated notification logic adding 11 days to the enrollment date would place me at March 14 3:11 PM.
This is past the 2AM required send time so the notification should be sent the following day - March 15 at 2:00AM.  The message was sent today at 2:00 AM.

Here is the rabbit hole:
 

I propose that we have a two factors creating the error here:

Following the logic that all notification times will be calculated based on a single time zone (CET perhaps) with modifiers, the DST effect has the notification triggering one hour later in the single time zone to ensure 2AM EST - send time would now equate to 3AM.

For the second part I propose that the determination to send calculation is based upon a straight number comparison - enrollment time for this example is viewed in the admin UI as 03:11:12. 

So 3 in the enrollment with 3 on the send time (my assumption extends to ignoring minutes and seconds) gives an "equal" result with the send decision being made on the send time being less than or equal to the enrollment time.

This is one potential explanation for why the calculation is ignoring the clear 12 hour shortfall in completing a day.

This issue is definitely bigger on the inside :-)

Howdy folks. Do we know if this impacts notifications too? I currently have a notification that started sending an hour later, lining up with daylight savings time, but support doesn’t think it’s the case. I’m fairly confident it was configured for 9 am in our system, and now shows 10 am. I’m assuming this is because they technically tie it to GMT/UTC. Do we need to adjust our notification timing twice a year to combat the change? I’m still on the legacy notification system. 

​@caitlin I definitely have notifications that didn’t adjust for DST.  We have one for unfinished courses to managers that is scheduled for 6, but now is going out at 7.  I can just look back at e-mails in my inbox from last week to see the time change.

Think you just need to re-save the rule to get it working and aligned properly.

thankfully I only have one this impacts. This wouldn’t be feasible if I were managing a large number of scheduled notifications. 

I submitted an idea on this if anyone else wants to upvote it. It’s tied to notifications specifically. 

Ahh… seems like we’re still experiencing this problem. I had to reset one of my automations today. 

Does anyone know if notifications are still affected by this now that we’re on the NEW notification engine?