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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4