# Gladys didn't switch to winter time

**URL:** <https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428>\
**Category:** Configuration\
**Created:** [October 29, 2023, 5:28pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428 "2023-10-29T17:28:27Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![pierre-gilles](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/pierre-gilles/32/5886_2.png) [@pierre-gilles](https://community.gladysassistant.com/u/pierre-gilles)\
**Post date:** [October 30, 2023, 8:44am UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/13 "2023-10-30T08:44:54Z")

</div>

Hello everyone 🙂

Yes, it’s a known Gladys bug — we’ve already had the issue during clock changes in the past.

The problem comes from the library we use to schedule scenes ([node-schedule](https://github.com/node-schedule/node-schedule)); apparently they don’t handle clock changes well.

I saw a few threads discussing the issue:

> <https://github.com/node-schedule/node-schedule/issues/435>
>
> I have a job running every second.
> 
> Here in Belgium, the clock went from 2018-…10-28T03:00+02:00 to 2018-10-28T02:00+01:00. 
> 
> My scheduled job did not run for 1 hour after the change, and started running again at 2018-10-28T03:00+01:00. 
> 
> Probably the decision on whether or not to trigger the job is comparing local timestamps?

> <https://github.com/node-schedule/node-schedule/issues/267>
>
> There have been repeated issues about crashes and infinite loops caused by chang…ing the date, especially due to daylight savings time changes. See #11, #131, #132, #214, #208. This issue is aimed to be a consolidation of those issues and a final solution. It would be good if we could avoid closing this until we absolutely sure that this is fixed for good.
> 
> This issue has caused downtime for us two years running now (when the clocks go forward at the end of March in the UK), with \`0.1.13\` and \`0.1.16\`, and I've only just worked out that node-schedule is the cause.
> 
> Most of the issues above point to the \`while (true)\` loop in \`nextInvocationDate()\`, which can get stuck when \`Date\` either doesn't increment or jumps back unexpectedly. For example, it will increment one minute at a time... \`00:58:00\`, \`00:59:00\`... but then jumps back to \`00:00:00\` because \`01:00:00\` does not exist on the night of daylight savings time.
> 
> This has been reported for \`0.1.8\`, \`0.1.13\`, \`0.1.16\`. Apparently it's fixed every time, only to find a new report against the next version that it's still similarly broken. One comment said there was a complete overhaul of this to fix it once and for all in \`1.0.0\`, but I've just upgraded to \`1.1.0\` and it's \*\*\_STILL\*\*\_ broken! Daylight savings time... the endless source of bugs :(
> 
> To reproduce:
> 
> \`\`\`
> var sinon = require('sinon');
> var clock = sinon.useFakeTimers(+new Date(2016, 2, 26, 23, 59, 55), 'Date', 'setTimeout');
> console.log('NEW DATE', new Date());
> var schedule = require('node-schedule');
> setInterval(function () {
> clock.tick(1000);
> console.log('NEW DATE', new Date());
> }, 1000);
> 
> schedule.scheduleJob({ minute: 0 }, function () {
> console.log('MARK ' + new Date());
> });
> \`\`\`
> 
> Run the above with version \`0.1.16\` or \`1.1.0\` and it will go into an infinite loop when reaching \`01:00:00\`. Depending on the version it will may be running the job repeatedly or just constantly trying to work out the next job time.
> 
> It seems there are two variations of this bug:
> 1. \`nextInvocationDate\` going into an infinite loop trying to work out the date of the next instance
> 2. Running an event at \`00:00:00\`, working out the next event is at \`00:00:00\` (because \`01:00:00\` got changed back to \`00:00:00\`), running the event again, working out the next event is at \`00:00:00\` again, etc.
> 3. Any others?
> 
> What can be done to finally fix this for good? How might it be rewritten if we start with the assumption that \`Date\` is malicious and will \*\*actively try\*\* to cause an infinite loop if it can?
> 
> Thanks.

> <https://github.com/node-schedule/node-schedule/issues/34>
>
> Can this module has a way to set the timezone for job schedules?
> It seemed that …this repo hasn't been update for a long time.

We need to see whether we can find a fix via this library, or whether we should consider another library.

I created a GitHub issue:

> <https://github.com/GladysAssistant/Gladys/issues/1917>
>
> Gladys keep the old hour in scene after a daylight saving time change.
> Restarti…ng Gladys fixes the issue.
> 
> The issue comes from the \`node-schedule\` NPM library.
> 
> https://github.com/node-schedule/node-schedule/issues/435
> 
> https://github.com/node-schedule/node-schedule/issues/267
> 
> https://github.com/node-schedule/node-schedule/issues/34
> 
> We can either find a new library or try to fix this one
> 
> https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428

---

_[View the full topic](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428)._
