[Python-Dev] Vacation and possibly a new bug

[Stuart Bishop]

On Wednesday, July 23, 2003, at 08:42  AM, Neal Norwitz wrote:

>
> The patch below fixes test_time on RedHat 6.2/Alpha.  Since I don't
> understand the code, I haven't the slighest clue if the patch is
> correct or not.  But I do know what (365 * 24 * 3600) is.  :-)
> I don't know what ((365 * 24 + 6) * 3600) is supposed to represent.
> 1 year + 6 hours in seconds.  What's that?
>
> I've copied Stuart Bishop on this message as I believe he wrote
> all this code. The patches in http://python.org/sf/762934 haven't
> made the tests pass.

I'm following this thread (from an out of sync timezone).

I didn't change much in timemodule.c - I just shuffled some things
around a bit and added the tzset function (see the comment
at the start of inittimezone()).

I don't know why YEAR is defined as 365 days + 6 hours either. I
think it is there to account for leap years as others have mentioned.
It would be interesting to see what happens if a Redhat6.2 user
runs test_time.py with 'xmas2002 =3D 1040774400.0' changed
to 'xmas2002 =3D 914508000.0' in case it is a Y2K bug we only just=20
noticed :-)

I can't see why removing the '+6' would make any difference at all,
unless your OS doesn't understand leap years and your DST changeovers
are =B18 days of 1st Jan or 1 Jul (which is not the case for the =
AEST/AEDT
timezone being tested).

I think the existing algorithm is broken, as it assumes
that midnight Jan 1st UTC is always non-DST, and 'around July 1st UTC'
always DST in the northern hemisphere (reversing this in the
southern hemisphere). I'm sure there is at least one country where
this isn't true :-)

bcannon's tzset_AEST.diff patch can be improved (it doesn't check if the
system believes the whole year is entirely in DST). It also needs to
do the following:

time_t midyear =3D xmas - (365 * 24 * 3600 / 2);

if (strcmp(localtime(&midyear)->tm_zone, "AEST"))
     exit(1);

I'll make a patch when anon-cvs gets back up, unless someone beats
me to it.

> I'm not real comfortable including this in 2.3.  Although the
> worst that should happen is that it gives incorrect results
> (which may very well be happening now).

--=20
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/