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 :-)