# Gladys didn't switch to winter time **URL:** \ **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:** 13\ **Page:** 1
**Author:** ![bjm](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bjm/32/1753_2.png) [@bjm](https://community.gladysassistant.com/u/bjm)\ **Post date:** [October 29, 2023, 5:28pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/1 "2023-10-29T17:28:27Z")
Hello. Gladys did not switch to winter time. I have a scene that sends the daily production of my solar panel via Telegram at dusk. On October 28 I received it at 6:30 PM Today at 4 ---
**Author:** ![qleg](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/qleg/32/12290_2.png) [@qleg](https://community.gladysassistant.com/u/qleg)\ **Post date:** [October 29, 2023, 5:30pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/2 "2023-10-29T17:30:45Z")
I confirm the same behavior in my scenes. ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [October 29, 2023, 5:36pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/3 "2023-10-29T17:36:36Z")
Do you have the timezone correctly set in the Docker environment variables? `-e TZ=Europe/Paris` ---
**Author:** ![bjm](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bjm/32/1753_2.png) [@bjm](https://community.gladysassistant.com/u/bjm)\ **Post date:** [October 29, 2023, 5:42pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/4 "2023-10-29T17:42:51Z")
and how do we find this variable? ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [October 29, 2023, 5:44pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/5 "2023-10-29T17:44:14Z")
You can inspect the container with this command `docker inspect gladys | grep TZ` ---
**Author:** ![bjm](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bjm/32/1753_2.png) [@bjm](https://community.gladysassistant.com/u/bjm)\ **Post date:** [October 29, 2023, 5:46pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/6 "2023-10-29T17:46:28Z")
I connected via SSH I entered ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [October 29, 2023, 5:52pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/7 "2023-10-29T17:52:10Z")
> [@bjm](#): > > I ran your command; it didn’t return anything That means the Gladys container has no timezone. In the documentation, there are all the variables including the timezone (which allows the clock to change automatically) [Installation avec Docker | Gladys Assistant](https://gladysassistant.com/fr/docs/installation/docker/#lancer-un-container-gladys-assistant) If Gladys was installed a long time ago, maybe it wasn’t present yet 🤔 ---
**Author:** ![bjm](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bjm/32/1753_2.png) [@bjm](https://community.gladysassistant.com/u/bjm)\ **Post date:** [October 29, 2023, 5:55pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/8 "2023-10-29T17:55:31Z")
So this means that the variable is not present in the image for Raspberry Pi just to be sure I checked that the time zone was set to (GMT+01:00) Paris ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [October 29, 2023, 6:06pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/9 "2023-10-29T18:06:34Z")
Ah sorry, if it’s with the Gladys image for Raspberry Pi, it’s different. The timezone is based on `/etc/timezone` which is mounted as a volume in the container. Can you run the following commands? `cat /etc/timezone` `docker inspect -f '{{ .Mounts }}' gladys` ---
**Author:** ![bjm](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bjm/32/1753_2.png) [@bjm](https://community.gladysassistant.com/u/bjm)\ **Post date:** [October 29, 2023, 6:08pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/10 "2023-10-29T18:08:30Z")
> [@cicoub13](#): > > docker inspect -f ‹ {{ .Mounts }} › gladys ```auto pi@gladys:~ $ cat /etc/timezone Europe/Paris pi@gladys:~ $ docker inspect -f '{{ .Mounts }}' gladys [{bind /dev /dev true rprivate} {bind /etc/localtime /etc/localtime ro false rprivate} {bind /etc/timezone /etc/timezone ro false rprivate} {bind /run/udev /run/udev ro false rprivate} {bind /sys/class/gpio /sys/class/gpio true rprivate} {bind /var/lib/gladysassistant /var/lib/gladysassistant true rprivate} {bind /var/run/docker.sock /var/run/docker.sock true rprivate}] pi@gladys:~ $ ``` ---
**Author:** ![cicoub13](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/cicoub13/32/4482_2.png) [@cicoub13](https://community.gladysassistant.com/u/cicoub13)\ **Post date:** [October 29, 2023, 6:12pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/11 "2023-10-29T18:12:10Z")
Everything is OK 🤔 I think restarting Gladys will resolve the problem. But it’s best to wait until tomorrow; @pierre-gilles will surely be able to ask for more information or provide a lasting solution. ---
**Author:** ![bjm](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/bjm/32/1753_2.png) [@bjm](https://community.gladysassistant.com/u/bjm)\ **Post date:** [October 29, 2023, 6:17pm UTC](https://community.gladysassistant.com/t/gladys-nest-pas-passe-a-lheure-dhiver/8428/12 "2023-10-29T18:17:13Z")
I restarted Gladys. ---
**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")
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: > > > 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? > > > 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. > > > 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: > > > 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