# Bug affichage calendrier **URL:** \ **Category:** Configuration\ **Tags:** bug\ **Created:** [Septembre 13, 2026, 1:55 UTC](https://community.gladysassistant.com/t/bug-affichage-calendrier/10857 "2026-09-13T13:55:19Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\ **Post date:** [Septembre 13, 2026, 1:55 UTC](https://community.gladysassistant.com/t/bug-affichage-calendrier/10857/1 "2026-09-13T13:55:19Z")
Je crois que j’ai un souci avec l’affichage dans le calendrier Au mois d’octobre j’ai 2 fois le 25 un dimanche et le lundi. ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/3/7/375bb6e36cef15a9d50dc1d8b8d7f8d7e404af8d.png) Dans la vue par semaine le jour va de 22H à 21H ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/5/5/5526088fbb4f17d0d2a65b2b8e900bf03dfc5baf.png) Idem dans la vue jour ![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/0/d/0d92e7e7f49f5306c7d4c2b595557d1101683758.jpeg) Est-ce que d’autres personne ont remarqué ces problèmes? ---
**Author:** ![prohand](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/prohand/32/15713_2.png) [@prohand](https://community.gladysassistant.com/u/prohand)\ **Post date:** [Septembre 13, 2026, 2:16 UTC](https://community.gladysassistant.com/t/bug-affichage-calendrier/10857/2 "2026-09-13T14:16:30Z")
Hello, J’ai effectivement les mêmes bugs et sur la vue joue pas qu’au mois d’octobre 😅 ---
**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\ **Post date:** [Septembre 13, 2026, 7:45 UTC](https://community.gladysassistant.com/t/bug-affichage-calendrier/10857/3 "2026-09-13T19:45:47Z")
![image](https://gladys-assistant-community.b-cdn.net/uploads/default/original/3X/6/c/6c330366845c2115c2ba6295a810ce4df68bc07c.png) bug sur mars 2027 ou les jours grisé en fin de mois ne sont pas correct. Du coup je vais ouvrir une PR pour corriger tous ces points ---
**Author:** ![Will\_71](https://gladys-assistant-community.b-cdn.net/user_avatar/community.gladysassistant.com/will_71/32/9582_2.png) [@Will\_71](https://community.gladysassistant.com/u/Will_71)\ **Post date:** [Septembre 13, 2026, 8:40 UTC](https://community.gladysassistant.com/t/bug-affichage-calendrier/10857/4 "2026-09-13T20:40:44Z")
J’ai creusé ce bug, il y a en fait trois symptômes distincts qui partagent une seule et même cause. La cause Le front utilise dayjs pour tous ses calculs de dates. Une box du tableau de bord (EDF Tempo) chargeait le plugin timezone de dayjs pour lire l’heure de Paris. Le problème : dayjs.extend() modifie globalement dayjs, pour toute l’application. Et la bibliothèque du calendrier (react-big-calendar) contient ce test : // if the timezone plugin is loaded, then use the timezone aware version const dayjs = dayjsLib.tz ? dayjsLib.tz : dayjsLib; Dès que le plugin est présent, le calendrier bascule tous ses calculs sur dayjs.tz, qui se comporte différemment : - il interprète certaines dates comme de l’UTC → la grille horaire glisse de 2h - add(1, ‹ jour ›) ajoute 24h absolues, alors que le jour du passage à l’heure d’hiver en dure 25 → on retombe à 23h le même jour, d’où la date affichée deux fois - startOf(‹ mois ›) se décale d’une heure, ce qui fausse la comparaison des mois → le grisage s’inverse Point important : cette box était importée statiquement avec toutes les autres, donc le plugin se chargeait même si vous n’utilisiez jamais EDF Tempo. Le correctif Plutôt que de rustiner le calendrier, j’ai supprimé la cause : la box EDF Tempo utilise maintenant Intl.DateTimeFormat (natif, sans effet de bord) pour lire l’heure de Paris. Le comportement métier est identique — les heures pleines/creuses restent définies en heure française quel que soit votre fuseau. Il reste un correctif dans le calendrier, pour un bug indépendant de celui-ci : le jour du changement d’heure affichait 26 lignes horaires en octobre et 22 en mars au lieu de 24, et les événements y étaient mal positionnés (un rendez-vous de 14h s’affichait à 13h26). La PR: > > > Description : > > \## The problem > > Three calendar display bugs reported on the f…orum, all sharing one root cause: > > 1. In week and day views, the time gutter started at 22:00 instead of 00:00 — > shifted by the local UTC offset > 2. In month view, a date appeared twice around the October DST switch (the > "25th shown twice, on the Sunday and on the Monday") > 3. In month view, the last days of the month were greyed as out-of-range while > the first days of the next month looked in-range > > \## The root cause > > The EDF Tempo box loaded dayjs's \`timezone\` plugin to read the Paris hour. > \`dayjs.extend()\` mutates the shared dayjs singleton, and react-big-calendar > switches its whole date arithmetic over to \`dayjs.tz\` as soon as the plugin is > present: > > \`\`\`js > // react-big-calendar/lib/localizers/dayjs.js > const dayjs = dayjsLib.tz ? dayjsLib.tz : dayjsLib; > > dayjs.tz then behaves differently on three paths: > > ┌──────────────────────────────┬────────────────────┬─────────────────────────────────────────────────────────┐ > │ Call │ Without the plugin │ With the plugin │ > ├──────────────────────────────┼────────────────────┼─────────────────────────────────────────────────────────┤ > │ merge(date, min) │ 00:00 local │ 22:00 the day before (string reparsed as UTC) │ > ├──────────────────────────────┼────────────────────┼─────────────────────────────────────────────────────────┤ > │ add(25 Oct, 1 day) │ 26 Oct 00:00 │ 25 Oct 23:00 (24 absolute hours, but that day lasts 25) │ > ├──────────────────────────────┼────────────────────┼─────────────────────────────────────────────────────────┤ > │ startOf('month') on 30 March │ 28 Feb 23:00 │ 28 Feb 22:00 (an hour off past the DST switch) │ > └──────────────────────────────┴────────────────────┴─────────────────────────────────────────────────────────┘ > \`\`\` > > Each one maps to one of the symptoms above: the shifted gutter, the duplicated > day, and the inverted greying. > > The box is imported statically in Box.jsx along with every other dashboard > box, so the plugin loaded for everyone — including users who never used EDF > Tempo. That is why the bug looked unrelated to it on the forum. > > The fix > > Rather than patching the calendar around each symptom, this removes the cause: > EDF Tempo now reads the Paris hour with Intl.DateTimeFormat, which is native > and has no global side effect. The business behaviour is unchanged — Tempo peak > hours stay defined in French local time whatever timezone the browser sits in > (verified against dayjs.tz from a non-Paris timezone, on winter midnight, > summer midnight and midday: identical values). > > An ESLint rule blocks the plugin import so this cannot silently come back. > > Also fixes an unrelated react-big-calendar bug the DST day exposed: the day and > week views size their grid from getTotalMin(), which returns elapsed minutes > (1500 in autumn, 1380 in spring), while event placement already folds the shift > away and works on a 1440 minute scale. The grid got 25 rows in October and 23 in > March, and a 2pm event rendered at 1:26pm on the October change. > > Testing > > Verified without the plugin across Europe/Paris, America/New\_York, > Australia/Sydney, Pacific/Auckland, America/Santiago and UTC: > > \- time gutter starts at 00:00 with 24 rows, every day of 2026 > \- month view 2024-2030: no duplicated day, greying matches the displayed month > > One expected exception: in America/Santiago on 6 September 2026 the gutter > starts at 01:00 with 23 rows — midnight does not exist there that day, the clock > jumps from 23:59 to 01:00. That is correct behaviour. > > > Fixes the bugs reported at > https://community.gladysassistant.com/t/bug-affichage-calendrier/10857 > > \### Checklist > > \- \[X\] If a forum topic or GitHub issue exists, the description links it (\`Forum: https://community.gladysassistant.com/t/...\` or \`Closes #...\`) > \- \[X\] Tests pass: \`cd server && npm run coverage\` (Codecov requires 100% coverage on changed lines) and Cypress (\`npm run cypress:run\`) if the UI changed > \- \[X\] Linter and prettier pass on both front and server (\`npm run eslint\`, \`npm run prettier\`) > \- \[X\] No undocumented breaking change > > 🤖 Generated with Claude Code