[issue762963] timemodule.c: Python loses current timezone
Stephen White added the comment: Debian appear to have applied this patch, and it seems to be causing problems: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593461 -- nosy: +Stephen.White ___ Python tracker <http://bugs.python.org/issue762963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue762963] timemodule.c: Python loses current timezone
Stephen White added the comment:
The patch, issue762963.diff, is broken. It is calling mktime on a struct tm
that is initialized to zeros. This means that it should be filling in the
missing fields based on their correct values for the date 1st Jan 1900, which
is incorrect behaviour as the whole method should be choosing appropriate
values based on the date provided by the user.
However in practice this call to mktime is effectively a no-op on 32bit
systems. The reason for this is:
The mktime(p) call is at the top of the method, straight after the memset(p,
'\0', ...) call. This means p->tm_year is zero. According to the definition
of struct tm a zero in the year field means 1900.
On a 32bit system the earliest date handled by libc is 2**31 seconds before the
Epoch (1st Jan 1970);
>>> time.strftime("%Y-%m-%d %H:%M:%S %Z", time.localtime(-2**31))'1901-12-13
>>> 20:45:52 GMT'
So dates in the year 1900 cannot be handled by libc, and in this situation the
mktime(p) call makes no attempt to normalise the provided data (or fill in
missing values).
The situation is different on 64bit systems. Here there is no problem with a
much wider range of dates. This means that dates during 1900 *are* handled by
libc, and so it does attempt to normalise the data and fill in missing values.
For most of the fields in the structure whether or not mktime fills in or
alters their value is of little consequence, as they're immediately overwritten
by the call to PyArg_Parse. However the contents of the tm_gmtoff & tm_zone
fields are not overwritten.
If the mktime call does nothing (as on a 32bit system) then tm_zone remains
NULL throughout.
If the mktime call does fill in missing values (as on 64bit systems) then
tm_zone is set to the appropriate timezone for the zero time (the beginning of
the year 1900). In our case this is always "GMT", because the beginning of the
year is in winter (when we use GMT).
If tm_zone is set when the structure is passed into strftime then it is
honoured. So if it has been set by mktime to be GMT then strftime will output
GMT, regardless of the correct timezone string for the actual time provided.
--
___
Python tracker
<http://bugs.python.org/issue762963>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12431] urllib2.Request.get_full_url() broken in newer versions of Python
Stephen White added the comment:
Just to confirm that it was a release, but 2.7.1 so not the current. Doesn't
appear to happen in Python 2.7 (as shipped with Fedora Core 14) or in Python
2.7.2.
C:\>\Python27\python.exe
Python 2.7.1 (r271:86832, Nov 27 2010, 17:19:03) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> urllib2.Request("http://host/path#fragment";).get_full_url()
'http://host/path'
>>>
Upgrading our affected Windows boxes to Python 2.7.2 seems to solve the problem.
We're happy for this bug to remain closed.
--
nosy: +Stephen.White
___
Python tracker
<http://bugs.python.org/issue12431>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
Stephen White added the comment: 32bit apps can query the 64bit registry, using the appropriate security and access rights options such as KEY_WOW64_64KEY (0x0100). Similarly KEY_WOW64_32KEY can be used for 64bit apps to read/write the 32bit registry without having to have knowledge of how the Wow6432Nodes are arranged . These mean that a 64bit aware app, whether compiled as 64 or 32 bits, can access the alternative view of the registry. http://msdn.microsoft.com/en-us/library/ms724897(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms724878(VS.85).aspx For example if you have both 64 and 32 bit copies of Python installed then a Python app running under the 32bit copy of Python can query the location of the 64bit copy of Python using code like: key64 = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "Software\\Python\\PythonCore\\2.6\\PythonPath", 0, _winreg.KEY_READ + 0x0100) _winreg.QueryValue(key, "") C code can do similarly. -- nosy: +Stephen.White ___ Python tracker <http://bugs.python.org/issue6792> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13817] deadlock in subprocess while running several threads using Popen
Changes by Stephen White : -- nosy: +Stephen.White ___ Python tracker <http://bugs.python.org/issue13817> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14308] '_DummyThread' object has no attribute '_Thread__block'
Stephen White added the comment: Glad this is fixed. Attached is a Python 2.7 file that demonstrates the problem in a pretty minimal way in case it is of any use to anyone. -- nosy: +Stephen.White Added file: http://bugs.python.org/file25511/bad-thread.py ___ Python tracker <http://bugs.python.org/issue14308> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
