In theory this should fix it. I cannot remember why it was forced to -1 (automatic detection), but during rollback period this would result in uncorrect time value being returned by mktime().

Index: src/libs/zbxcommon/misc.c
===================================================================
--- src/libs/zbxcommon/misc.c	(revision 74121)
+++ src/libs/zbxcommon/misc.c	(working copy)
@@ -1581,7 +1581,6 @@
 	int		nextcheck = 0, current_nextcheck;
 
 	tm_start = *(localtime(&now));
-	tm_start.tm_isdst = -1;
 
 	for (; NULL != interval; interval = interval->next)
 	{

wiper No the real problem is that the tm structure passed to mktime is adjusted by daylight saving changes, which leads to unpredicted results. I don't remember such behavior before and documentation mentions only that tm_isdst, tm_yday and tm_wday could be changed during mktime() call.

Also there is additional problem that with this issue fixed there might be 1h gaps in scheduled checks after daylight saving changes.

dmitrijs.borisenko User already complains that first scheduled check after time change is 1 hour off

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-12965

This fixes looping issue and also the bug where the next scheduled check after time change might be off (depending on specified intervals).

However there still will be gap after daylight saving time has been applied for checks with repeating intervals. For example scheduled check with interval m/15 would be polled at:

2017.10.29 02:45:00 (1) +900
2017.10.29 03:00:00 (1) +900
2017.10.29 03:15:00 (1) +900
2017.10.29 03:30:00 (1) +900
2017.10.29 03:45:00 (1) +900
2017.10.29 04:00:00 (0) +4500
2017.10.29 04:15:00 (0) +900
2017.10.29 04:30:00 (0) +900
2017.10.29 04:45:00 (0) +900
2017.10.29 05:00:00 (0) +900
2017.10.29 05:15:00 (0) +900

Created ZBXNEXT-4206 regarding improvements of scheduled times after daylight saving time transition.

I'm attaching the patch with solution by wiper and my minor nitpicking in r74256, r74266. This patch solves the looping problem.

However, I have a feeling that scheduling intervals may not use mktime() correctly and overuse this quite expensive call. Since we are too late for this year's winter time transition anyway, let's spend some more time and provide a more comprehensive improvement.

another DST-related issue - ZBX-9387

Released in:

• pre-4.0.0alpha8 r81483

This issue was moved to fixed state - did that include the more comprehensive improvements Glebs suggested, or are there still known issues?

Yes, time conversions/validation and daylight saving detection was rewrtitten. And no, none that we know of.

Great news, thank you.

Hey guys!

1. This issue lacks the regular "Fixed in pre-x.y.z rNNNNN" comment.
2. It claims that Fixed versions are numerous including 3.0 and 3.4, but the only mention of this issue I could find in the ChangeLog is in 4.0.0alpha8 section.
3. There is ZBX-15085 which looks very similar to this one, which is very strange provided this is supposed to be fixed in 3.4.13.

Please clarify.

I've tried to replicate the scenario from ZBX-15085 in a unit test for calculate_item_nextcheck():

test case: ZBX-15085
in:
  item type: ZABBIX
  delay: 0;h0m1-30/2s50
  timezone: :Europe/London
  at: 2018-10-28 00:01:51 +01:00
out:
  checks:
    - 2018-10-28 00:03:50 +01:00
    - 2018-10-28 00:05:50 +01:00
    - 2018-10-28 00:07:50 +01:00
    - 2018-10-28 00:09:50 +01:00
    - 2018-10-28 00:11:50 +01:00
    - 2018-10-28 00:13:50 +01:00
    - 2018-10-28 00:15:50 +01:00
    - 2018-10-28 00:17:50 +01:00
    - 2018-10-28 00:19:50 +01:00
    - 2018-10-28 00:21:50 +01:00
    - 2018-10-28 00:23:50 +01:00
    - 2018-10-28 00:25:50 +01:00
    - 2018-10-28 00:27:50 +01:00
    - 2018-10-28 00:29:50 +01:00
    - 2018-10-29 00:01:50 +00:00

And trunk behaves as expected.

Thanks, wiper! Could you also check Fix Version/s?

I think the initial intention was to fix also in 3.0, 3.4, so it might be missing in those branches. Need to double check it.

As far as I remember the plan was to develop the fix for trunk to benefit from unit tests and then backport the fix when it's ready.

As I see, this ZBX-12965 was merged to trunk only, so included to 4.0 only.
I cannot remove incorrect versions form "Fix versions" field because their tags are archived already.

Version can be unarchived briefly, but project administration rights are required for this.

(1) The changelog entry has an excess leading "- ".

wiper: Better late than never, fixed in 4.0 r89528 and trunk r89527

Created ZBX-15132 to handle backporting.