<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 26 Oct 2009, at 12:53, Matthias Flacke wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>this change is causing the wrong reschedule:<br><a href="http://nagios.cvs.sourceforge.net/viewvc/nagios/nagios/base/utils.c?r1=1.236&r2=1.237&view=patch">http://nagios.cvs.sourceforge.net/viewvc/nagios/nagios/base/utils.c?r1=1.236&r2=1.237&view=patch</a><br><br>It has been applied on 15th of January 2009 and introduced some<br>statements<br><br>t->tm_isdst=-1;<br><br>into base/utils.c.<br><br>Affected are all Nagios versions >= 3.1.0.<br><br>I could reproduce it here: if the patch above is backed out, the<br>scheduling behaves correctly.<br></div></blockquote><div><br></div><div><br></div><div>I've managed to get a libtap test case with the failure now. As you correctly say, removing the t->tm_isdst=-1 in utils.c fixes it.</div><div><br></div><div>However, the fact it works is lucky. </div><div><br></div><div>The check is that the scheduled time is between a date_range_start and a date_range_end. This date_range_end is based on the timeperiod definitions. However, an end point of 00:00 is calculated as 24*60*60. Obviously, this is wrong on the day that the clocks go back as there are 25 hours in that day.</div><div><br></div><div>So removing tm_isdst gets the calculation for the epoch time wrong, but that luckily works because the time falls within the 24 hour period.</div><div><br></div><div>I've applied the patch to remove that single tm_isdst. </div><div><br></div><div>Tests are also added now, for this specific issue. </div><div><br></div><div><div>Long term, I think it is correct that the isdst flag be set, but there are other problems that are lurking in the code, such as the calculation for the next appropriate time.</div><div><br></div><div>Any comments?</div><div><br></div></div><div>Ton</div><div><br></div><div><br></div></div></body></html>