[ZBX-20162] Maintenance Period interrupted by Daylight Saving CEST to CET Created: 2021 Nov 02  Updated: 2022 Feb 12  Resolved: 2022 Feb 12

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: None
Fix Version/s: None

Type: Problem report Priority: Trivial
Reporter: H.L. Assignee: Antons Sincovs
Resolution: Won't fix Votes: 0
Labels: maintenance, period, server
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

zabbix-agent.x86_64 5.0.6-1.el7 @zabbix
zabbix-apache-conf-scl.noarch 5.0.6-1.el7 @zabbix-frontend
zabbix-release.noarch 5.0-1.el7 installed
zabbix-server-mysql.x86_64 5.0.6-1.el7 @zabbix
zabbix-web.noarch 5.0.6-1.el7 @zabbix-frontend
zabbix-web-deps-scl.noarch 5.0.6-1.el7 @zabbix-frontend
zabbix-web-mysql-scl.noarch 5.0.6-1.el7 @zabbix-frontend

Attachments: JPEG File DS-Bug_Groups.JPG     JPEG File DS-Bug_History_Graph.JPG     JPEG File DS-Bug_Maintenance.JPG     JPEG File DS-Bug_Periods.JPG    
Issue Links:
Causes
causes ZBXNEXT-7463 Prolong or shorten maintenance period... Open

 Description   

It seems the maintenance period is interrupted by daylight saving from CEST to CET. Hosts which where in maintenance mode without data collection, where monitored and triggered in a timeframe between 31.10.2021 23:00 and 31.10.2021 23:59. Because of this we got a lot of false alarms, which trigger our emergency response team. Since we had daylight saving on 31.10.2021 at 03:00 this day had 25 hours. I guess this is the reason our maintenance period was interrupted for 1 hour.
As you can see in the screenshots we have a special host group for hosts in maintenance mode for an unknown period. Thus this maintenance period should last "for ever" as long as this host is in that host group.

Steps to reproduce:

  1. Create host with icmp ping item and trigger, which is activly monitored
  2. Block icmp to that host or switch the host off, wait for trigger.
  3. Create a maintenance window as in the screenshots on a daily base and a schedule of 0:00 every day, lasting for 1 day.
  4. Put host into "maintenance" host group
  5. Create a trigger action for this host if not reachable. Pause operations for suppressed problems.
  6. Set system time to 30.10.2021 23:59 CEST
  7. On 31.10.2021 03:00 CEST the System will switch to 31.10.2021 02:00 CET
  8. Wait until 31.10.2021 23:00 CET

Result:

This host in maintenance host group will be monitored again. It is out of maintenance mode. The trigger action of this host will be fired.
See the screenshot of the ping history graph.

Expected:
Systems in maintenance host group shall not be monitored and trigger no alarms.

 Comments   
Comment by Antons Sincovs [ 2022 Jan 31 ]

Hello, H.L.

Thank you for the observation. Though it seems like a bug - actually it is not. As Zabbix internal logic evaluates 1 day as 24 hours. So when turning clocks back by 1 hour on the DST day in Autumn the day actually has 25 hours instead of the usual 24. But Zabbix still calculates 1 day period as 24 hours and this leads to a maintenance period starting at 0 hour ending at the 23rd (24 -1) hour of such a special (DST) day. On the DST day in Spring - this very logic would lead to the situation where 24 hour maintenance period ends at the 1st hour of the next day as the DST day would have 23 hours.
I have created a documentation task for this matter https://support.zabbix.com/browse/ZBX-20511

Comment by H.L. [ 2022 Jan 31 ]

Hello Antons Sincovs

Thanks for your feedback. As you see in the problem description I already suspected that Zabbix calculates with a fixed 24 hours period per day. Per definition a daylight saving day has 23 to 25 hours. Thus, this is nothing a user should need to care of while creating maintenance windows. This is a bug and the zabbix code should take care of these situations. On such days it should calculate with 23 or 25 hours, not 24 hours. Think of a calendar app which displays every month as 31 days long. Of course, the user could care of that, but it is neither convenient nor intuitive and decreases the user experience. Further this bug creates false positives and produces needless workload for users.

Regards,

Holger

Comment by Antons Sincovs [ 2022 Feb 02 ]

Dear Holger!

I agree with you that it is not intuitive. But "day" here is not like a day in a calendaring app, but it is a period of time under which precisely 24 hours are aggregated. These periods are hardcoded. For example, we have 1 month period defined as 30 days and 1 year as 365 days. I have had a talk with developers and they will consider what can be done about it in regards to maintenance periods.

Also created a ZBXNEXT-7463 with the request for processing such cases.

Regards,

Antons

Generated at Thu May 01 07:40:47 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.