time module in python 2.6 not working correctly.

Bug #711541 reported by Troy Telford on 2011-02-01
This bug affects 1 person
Affects Status Importance Assigned to Milestone
python2.6 (Ubuntu)

Bug Description

Binary package hint: python2.6

Description: Ubuntu 10.10
Release: 10.10

  Installed: 2.6.6-5ubuntu1
  Candidate: 2.6.6-5ubuntu1
  Version table:
 *** 2.6.6-5ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
        100 /var/lib/dpkg/status

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'

# Output the time with correct DST string:
# date is (July 4, 2010)
print(time.strftime('%c %Z', time.localtime(1278260625)))

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-2.6.5-3.3.1.x86_64.rpm)
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.10.10

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: python 2.6.6-2ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-25.44-generic
Uname: Linux 2.6.35-25-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Tue Feb 1 15:17:43 2011
PackageArchitecture: all
 PATH=(custom, user)
SourcePackage: python-defaults

Related branches

Troy Telford (ttelford) wrote :
Craig J Copi (cbug) wrote :

The problem seems to be caused by the fix to bug 564607 ( https://bugs.launchpad.net/python/+bug/564607 ) which is a fix to issue 762963 in python ( http://bugs.python.org/issue762963 ). The "fix" doesn't seem settled in the python community. In the python2.6 source package the patch file in debian/patches/issue762963.diff contains the "fix".

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.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python2.6 - 2.6.7-3ubuntu1

python2.6 (2.6.7-3ubuntu1) oneiric; urgency=low

  * Regenerate debian/control for Ubuntu

python2.6 (2.6.7-3) unstable; urgency=low

  * Make the conflict against python-profiler a versioned conflict.
  * Don't run the bsddb3 tests on kfreebsd-*.
  * Don't run the benchmark on hurd-i386.
  * Treat Linux 3.x as Linux 2. Closes: #633015.
  * Revert the suggested patch for issue #762963. LP: #711541.
  * Don't add the bsddb multilib path, if already in the standard lib path.
 -- Scott Kitterman <email address hidden> Fri, 29 Jul 2011 20:41:23 -0400

Changed in python2.6 (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.