time module in python 2.6 not working correctly.
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| python2.6 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: python2.6
Description: Ubuntu 10.10
Release: 10.10
python2.6:
Installed: 2.6.6-5ubuntu1
Candidate: 2.6.6-5ubuntu1
Version table:
*** 2.6.6-5ubuntu1 0
500 http://
100 /var/lib/
As far as I'm aware, I have all timezone information on my system correct;
I've run 'dpkg-reconfigure tzdata' to set my timezone properly.
I have a simple script that demonstrates the problem:
import os, time
os.environ['TZ'] = 'US/Mountain'
time.tzset()
# Output the time with correct DST string:
# date is (July 4, 2010)
print(time.
The expected result is:
Sun Jul 4 10:23:45 2010 MDT
The actual result is:
Sun Jul 4 10:23:45 2010 MST
(MST/MDT) is not being reported properly in Ubuntu/Debian.
This problem only seems to exist in Python 2.x (at least for the package I have installed). If I run the same script with python3, the correct MST/DST is returned.
On a similar note, I've run the same test code on:
Debian (sid): same results as ubuntu 10.10
openSUSE 11.3: Correct results (python-
SLES 11: Correct results (python 2.6.0)
gentoo: correct results (python 2.6.2)
RHEL 5.5: Correct results (python 2.4.3)
OS X 10.6.6: Correct Results (python 2.6.6)
I'm certain the problem is not with the code because it runs on every non-debian based system I've tried. The problem also exists for a 'default' ubuntu install, so I doubt it's a system configuration issue.
My 'tzdata' package is 2010o-0ubuntu0.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: python 2.6.6-2ubuntu2
ProcVersionSign
Uname: Linux 2.6.35-25-generic x86_64
NonfreeKernelMo
Architecture: amd64
Date: Tue Feb 1 15:17:43 2011
PackageArchitec
ProcEnviron:
LANGUAGE=en_US:en
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: python-defaults
Related branches
| Troy Telford (ttelford) wrote | #1 |
| Craig J Copi (cbug) wrote | #2 |
| Launchpad Janitor (janitor) wrote | #3 |
| Changed in python2.6 (Ubuntu): | |
| status: | New → Fix Released |
The problem seems to be caused by the fix to bug 564607 ( https:/
The source of the problem seems to be the addition of a call to mktime. What the code does with the "fix" is to
(1) zero struct tm *p
(2) call mktime(p) which sets timezone/dst information
(3) then fill in the rest of the tm structure with the date/time we are converting
This leads to the wrong dst information being used if our current dst is not in agreement with the dst of the time we are converting. This issue is really in gettmarg().
Attached is a program that shows the problem. In this program a struct tm buffer is created and zeroed. mktime is then called and the elements of struct tm printed. Next the date/time entries are filled in and strftime() is called. Finally the timezone information is zeroed in the structure and strftime() is called again. I find the following results:
Ubuntu 10.10 or 11.04 machine:
0 0 0 31 11 -1 0 364 0 -18000 EST <-- Oddly some entries are set
Sun Jul 4 12:23:45 2010 EST <-- Incorrect timezone
Sun Jul 4 12:23:45 2010 EDT <-- correct timezone
Debian Squeeze machine:
0 0 0 0 0 0 0 0 0 0 (null)
Sun Jul 4 12:23:45 2010 EDT
Sun Jul 4 12:23:45 2010 EDT
OpenBSD4.8 machine:
0 0 0 0 0 0 0 0 0 0 (null)
Sun Jul 4 12:23:45 2010 EDT
Sun Jul 4 12:23:45 2010 EDT
Notice that the Ubuntu machines reset some of the fields:
tm_mday = 31
tm_mon = 11
tm_year = -1
tm_yday = 364
plus the timezone related fields. The Debian machine doesn't.
Perhaps this really is an issue in eglibc and/or some changes in eglibc have obviated the need for this patch.
On Ubuntu 11.04 the patch issue762963.diff is included in the source package for python2.7 but is NOT applied, thus the python test code given in the original report runs correctly.