Stephen White <stephen-python....@randomstuff.org.uk> 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 <rep...@bugs.python.org>
<http://bugs.python.org/issue762963>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
