This patch is a workaround for Macintosh, where the GUSI I/O library
(time, stat, etc) use the MacOS epoch of 1-Jan-1904 and the MSL C
library (ctime, localtime, etc) uses the (apparently ANSI standard)
epoch of 1-Jan-1900. Python programs see the MacOS epoch and we
convert values when needed.
a Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS block, but it
calls Py_BLOCK_THREADS anyway. The change moves Py_BLOCK_THREADS
to inside the if, so it's only executed when the function
actually returns unexpectedly.
only. Through some mysterious interaction, they would take 9 separate
arguments as well. This misfeature is now disabled (to end a
difference with JPython).
The test really wanted to distinguish between the two. So now we test
for __GLIBC__ instead. I have confirmed that this works for glibc and
I have an email from Christian Tanzer confirming that it works for
libc5, so it should be fine.
"""
The GNU folks, in their infinite wisdom, have decided not to implement
altzone in libc6; this would not be horrible, except that timezone
(which is implemented) includes the current DST setting (i.e. timezone
for Central is 18000 in summer and 21600 in winter). So Python's
timezone and altzone variables aren't set correctly during DST.
Here's a patch relative to 1.5.2b2 that (a) makes timezone and altzone
show the "right" thing on Linux (by using the tm_gmtoff stuff
available in BSD, which is how the GLIBC manual claims things should
be done) and (b) should cope with the southern hemisphere. In pursuit
of (b), I also took the liberty of renaming the "summer" and "winter"
variables to "july" and "jan". This patch should also make certain
time calculations on Linux actually work right (like the tz-aware
functions in the rfc822 module).
(It's hard to find DST that's currently being used in the southern
hemisphere; I tested using Africa/Windhoek.)
"""
He writes:
I had an off-by-1000 error in floatsleep(),
and the problem with time.clock() is that it's not implemented properly
on QNX... ANSI says it's supposed to return _CPU_ time used by the
process, but on QNX it returns the amount of real time used... so I was
confused.
guessing what happened when strftime() returns 0. Is it buffer
overflow or was the result simply 0 bytes long? (This happens for an
empty format string, or when the format string is a single %Z and the
timezone is unknown.) if the buffer is at least 256 times as long as
the format, assume the latter.
2-digit years are now converted using rules that are (according to
Fredrik Lundh) recommended by POSIX or X/Open: 0-68 mean 2000-2068,
69-99 mean 1969-1999.
2-digit years are now only accepted if time.accept2dyear is set to a
nonzero integer; if it is zero or not an integer or absent, only year
values >= 1900 are accepted. Year values 100-1899 and negative year
values are never accepted.
The initial value of time.accept2dyear depends on the environment
variable PYTHONY2K: if PYTHONY2K is set and non-empty,
time.accept2dyear is initialized to 0; if PYTHONY2K is empty or not
set, time.accept2dyear is initialized to 0.
to inside floatsleep(). This is necessary because floatsleep() does
the error handling and it must have grabbed the interpreter lock and
thread state before it can do so.
Guido van Rossum
Andrew M. Kuchling
Jeremy Hylton
Barry Warsaw
Jack Jansen