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

[Guest]

--Apple-Mail-352-1044322451
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed;
delsp=yes
Content-Transfer-Encoding: quoted-printable


On 20 Mar 2010, at 01:33, Holger Wei=DF wrote:

> * Albrecht Dre=DF [2010-03-18 19:29]:
>>
>> t=3Dlocaltime((time_t *)&test_time);
>> test_time_year=3Dt->tm_year;
>> test_time_mon=3Dt->tm_mon;
>> test_time_mday=3Dt->tm_mday;
>> test_time_wday=3Dt->tm_wday;
>>
>> /* calculate the start of the day (midnight, 00:00 hours) =20
>> when the specified test time occurs */
>> t->tm_sec=3D0;
>> t->tm_min=3D0;
>> t->tm_hour=3D0;
>> /* Removed for the moment. This fixes a bug where the =20
>> timeperiod is incorrectly calculated */
>> /* See t-tap/test_timeperiods for a test failure */
>> /* t->tm_isdst=3D-1; */
>> midnight=3D(unsigned long)mktime(t);
>>
>>
>> Regarding the tm_isdst field, this code "initialises" it implicitly =20=

>> by
>> calling localtime() but then assumes for the calculation of midnight
>> that the dst setting is still correct which may be plain wrong.
>>
>> Example: test_time is 1269734400 (Mar 28 01:00:00 2010 CET), midnight
>> will correctly be calculated as Mar 28 00:00:00 2010. If test_time =20=

>> is
>> 1269763200 (Mar 28 10:00:00 2010 CEST), midnight is calculated as =20
>> Mar 27
>> 23:00:00 2010 which is obviously wrong. This miscalculation is =20
>> fixed,
>> again, by properly initialising tm_isdst to -1.
>>
>> Thus, either the "tests" missed the dst change cases, or the real =20
>> use of
>> midnight is not midnight but something else.
>
> The real use of the midnight value is not "12 o'clock at night," but
> "the zero point of the local time of the day," which differs from "12
> o'clock at night" if tm_isdst changed since 12 o'clock at night. That
> is, the offset of 10:00 AM from this zero point is 36,000 seconds,
> regardless of whether tm_isdst changed since 12 o'clock at night.
>
>> In the latter case, the fix is of course to re-write the time span
>> calculation to work properly (taking into account that days may =20
>> also be
>> 23 or 25 hours long, when dst changes)
>
> What makes you believe that the code in question does not work =20
> properly?

Thankfully, Holger has opened my eyes to my "revert the tm_isdst=3D-1" =20=

position.

Holger said (on IRC) "there were two different cases in the code: (1) =20=

at most places in the code, tm_isdst was initialized just fine (by =20
localtime(3)), but (2) at other places, it was indeed used =20
uninitialized".

I've already fixed on occurrence of (1) (in =20
check_time_against_period()), and I think I've found the other =20
occurrence now (in get_next_valid_time()). This is now fixed with =20
updated test cases in test_timeperiods.c. There is one particular test =20=

that fails at the moment which I'm not sure how to fix - any ideas =20
would be appreciated (it is marked as a TODO so full tests will not =20
fail).

I think all other occurrences of tm_isdst=3D-1 are of type (2), so I am =20=

not planning on reverting those anymore.

Ton


--Apple-Mail-352-1044322451
Content-Type: text/html;
charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 20 Mar 2010, =
at 01:33, Holger Wei=DF wrote:* =
Albrecht Dre=DF <[email protected]> =
[2010-03-18 19:29]:<snip> =
       t=3Dlocaltime((time_t =
*)&test_time); =
       test_time_year=3Dt->tm_year; =
       test_time_mon=3Dt->tm_mon;<blockquote type=3D"c

...[email truncated]...


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