Re: [Nagios-devel] Fix for mktime() issue

[Guest]

On 15 Mar 2010, at 20:10, Albrecht Dre=DF wrote:

> Am 15.03.10 20:42 schrieb(en) Ton Voon:
>> This patch was applied to Nagios Core and was in 3.2.0. I've fixed =20=

>> a specific problem last year with timeperiods when DST moved back =20
>> one hour, but I didn't change the other occurrences of this patch. =20=

>> My feeling was to get a test case for the specific changes before =20
>> reverting the patch.
>> However, I think there are still some timezone issues (as mentioned =20=

>> by Mark Frost on nagios-users), so I'm thinking that I should =20
>> revert the entire patch and instead say that if you want to add the =20=

>> isdst=3D-1 in, then add test cases in.
>
> The POSIX standard says [1]
>
>
> A positive or 0 value for tm_isdst shall cause mktime() to presume =20
> initially that Daylight Savings Time, respectively, is or is not in =20=

> effect for the specified time. A negative value for tm_isdst shall =20
> cause mktime() to attempt to determine whether Daylight Savings Time =20=

> is in effect for the specified time.
>
>
> Thus, unless you know for sure that daylight savings is in effect or =20=

> not for a specific date, /not/ using tm_isdst wrong (iirc, the field was not initialised at all without my patch, =20=

> which may give random results).
>
> Note that tm_isdst 9899, i.e. broken systems which do not implement POSIX (read: =20
> Winbloze) may fail here. Probably the only resort is to use utc =20
> exclusively.
>
>> Opinions?
>
> What should be the purpose of a test case if the code strictly =20
> follows POSIX?

Because the test cases proves real-world usage, rather than some spec?

In t-tap/test_timeperiods.c, I've got tests for a specific case of =20
what happened over the DST change in the autumn. Adding the =20
tm_isdst=3D-1 gives errors, whereas undefined works.

What I don't have, are tests for the other 18 cases where is_dst has =20
been initialised, and so I didn't revert those other changes. But my =20
opinion is now that this is too cautious and we should just revert =20
back to Nagios pre-3.2.0 behaviour.

So what I am proposing is:
* remove all the is_dst initialisations (because I don't want to =20
add new test cases and this is a recent change and Nagios didn't have =20=

issues here before)
* only add specific cases back when there is a test case that =20
proves that it should be initialised

The only way to prove this is running tests. Maybe some platforms =20
implement POSIX different. The best way to tell is to have test cases =20=

that run on your system of choice and report to Tinderbox. There are =20
currently three servers running Tinderbox builds at the moment. I'm up =20=

for anyone adding more: http://tinderbox.nagios.org and =
http://tinderbox.nagios.org/nagios/status.html

Ton






This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]