[issue762963] timemodule.c: Python loses current timezone

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
resolution:  -> out of date
status: open -> closed
superseder:  -> Time zone-capable variant of time.localtime

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue762963] timemodule.c: Python loses current timezone

[Brett Cannon]

Changes by Brett Cannon br...@python.org:


--
nosy:  -brett.cannon

___
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

[issue762963] timemodule.c: Python loses current timezone

[Stephen White]

Stephen White stephen-python@randomstuff.org.uk 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 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

[issue762963] timemodule.c: Python loses current timezone

[Jon Siddle]

Changes by Jon Siddle j...@corefiling.co.uk:


--
nosy: +jonsiddle

___
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

[issue762963] timemodule.c: Python loses current timezone

[Stephen White]

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

[issue762963] timemodule.c: Python loses current timezone

[Paul Boddie]

Paul Boddie p...@boddie.org.uk added the comment:

I don't understand how this bug and its patches are still active. It's 
difficult for me to remember what I was doing in early 2007 when I started 
working on issue #1667546, but I can well imagine that it was in response to 
this and a number of related bugs. Looking at #1667546, it's clear that the 
work required to handle time zones is not at all as trivial as the patches 
attached to this issue appear to be.

--

___
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

[issue762963] timemodule.c: Python loses current timezone

[Alexander Belopolsky]

Alexander Belopolsky belopol...@users.sourceforge.net added the comment:

I agree with Martin.  A proper fix would be to use tm_gmtoff explicitly where 
available and carry it in time.struct_time.

See issue1647654 and issue4086.

Interestingly, the issue does not show up on OSX, which being a BSD derivative 
does have tm_gmtoff in struct tm.

While I don't have an affected system to test the patch, it does not look right 
to me.  I would think mktime() should be called after PyArg_Parse, not before 
because tm_gmtoff may be different for different times.

--

___
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

[issue762963] timemodule.c: Python loses current timezone

[Alexander Belopolsky]

Alexander Belopolsky belopol...@users.sourceforge.net added the comment:

Another related issue is issue1667546.

--

___
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

[issue762963] timemodule.c: Python loses current timezone

[Alexander Belopolsky]

Changes by Alexander Belopolsky belopol...@users.sourceforge.net:


--
nosy: +belopolsky

___
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

[issue762963] timemodule.c: Python loses current timezone

[Grant Bowman]

Grant Bowman grant...@gmail.com added the comment:

Is there anything others like me can do to help get this fixed?

--
nosy: +grantbow

___
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

[issue762963] timemodule.c: Python loses current timezone

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

Review the code, test the patch, confirm that it fixes the problem and doesn't 
break anything else, and report your results here.  That doesn't guarantee that 
it will get applied, but it definitely helps.

--
nosy: +r.david.murray

___
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

[issue762963] timemodule.c: Python loses current timezone

[Paul Boddie]

Paul Boddie p...@boddie.org.uk added the comment:

Well, this still doesn't work for me. I'm running Kubuntu 8.04 (libc6 package 
version 2.7-10ubuntu5) and reside in the CEST time zone, yet attempting to 
display the time zone always seems to give +. Here are the failing tests, 
too:

==
FAIL: test_tm_gmtoff1 (__main__.TimeTestCase)
--
Traceback (most recent call last):
  File Lib/test/test_time.py, line 225, in test_tm_gmtoff1
time.strftime(%z), time.strftime(%z, time.localtime()))
AssertionError: '+0200' != '+'

==
FAIL: test_tm_gmtoff2 (__main__.TimeTestCase)
--
Traceback (most recent call last):
  File Lib/test/test_time.py, line 238, in test_tm_gmtoff2
time.strftime(%z, time.localtime()), +)
AssertionError: '+' == '+'

--

___
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

[issue762963] timemodule.c: Python loses current timezone

[Brian Curtin]

Brian Curtin cur...@acm.org added the comment:

Here's an updated version of the previous patches with the test included in 
test_time.py. The test fails on Linux before the timemodule.c file is changed, 
then it passes once applied.

--
keywords: +needs review
nosy: +brian.curtin
stage:  - patch review
type:  - behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5
Added file: http://bugs.python.org/file15934/issue762963.diff

___
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

[issue762963] timemodule.c: Python loses current timezone

[Christian Heimes]

Changes by Christian Heimes:


--
versions: +Python 2.5, Python 2.6


Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue762963

___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com