--=-nZ0seFuV8hPegk9GW5mm
Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Am 18.03.10 03:09 schrieb(en) eponymous alias:
> --- On Tue, 3/16/10, Ton Voon wrote:
>> In t-tap/test_timeperiods.c, I've got tests for a specific case of what =
happened over the DST change in the autumn. Adding the tm_isdst=3D-1 gives =
errors, whereas undefined works.
>=20
> Huh??? There's no such thing as undefined in C. There's a bit pattern o=
f some sort in that data cell, you'd better believe it. Deliberately blindi=
ng yourself to what it is just leaves you open to all manner of potential m=
ischief when it sometimes turns out not to contain what you expect it to.
That's *exactly* my point! Basically, it's like writing some random value =
to it.
>> (because I don't want to add new test cases and this is a recent change =
and Nagios didn't have issues here before)
>=20
> That's a recipe for disaster, introducing deliberate ambiguity into the c=
alculation.
Again, I 100% agree with you here.
> If you don't trust the mktime() implementation, then a few test cases run=
outside of Nagios itself should be able to prove that before the software =
is even built.
That was the purpose of my test app. It works as advertised by POSIX/ISO 9=
899 on Linux 32 and 64 bit, and on Mac OS X 10.4.
Basically Ton's approach as far as I understand it is like in function chec=
k_time_against_period() of base/utils.c:
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) 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 timeperiod i=
s 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 by call=
ing 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 is 126976320=
0 (Mar 28 10:00:00 2010 CEST), midnight is calculated as Mar 27 23:00:00 20=
10 which is obviously wrong. This miscalculation is fixed, again, by prope=
rly initialising tm_isdst to -1.
Thus, either the "tests" missed the dst change cases, or the real use of mi=
dnight is not midnight but something else. In the latter case, the fix is =
of course to re-write the time span calculation to work properly (taking in=
to account that days may also be 23 or 25 hours long, when dst changes) ins=
tead of shifting midnight around.
Best, Albrecht.
--=-nZ0seFuV8hPegk9GW5mm
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
iD8DBQBLonEqn/9unNAn/9ERAq2AAKCGuHpEQYBfSf+PkRLk5QBegLlgHwCgv/Fb
IMgTIGPyc66E5+a3t3XwtB8=
=oMop
-----END PGP SIGNATURE-----
--=-nZ0seFuV8hPegk9GW5mm--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]