homepage

test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x": 'AEST-10AEDT-11,M10.5.0,M3.5.0' timezone becomes 'EST'.
======================================================================
FAIL: test_tzset (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_time.py", line 209, in test_tzset
 self.assertTrue(time.tzname[0] == 'AEST', str(time.tzname[0]))
AssertionError: False is not true : EST
----------------------------------------------------------------------
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%207.2%203.x/builds/1705/steps/test/logs/stdio
See also http://en.wikipedia.org/wiki/Time_in_Australia 

On Wed, Apr 20, 2011 at 9:53 AM, STINNER Victor <report@bugs.python.org> wrote:
..
> test_time.test_tzset() fails on "x86 FreeBSD 7.2 3.x": 'AEST-10AEDT-11,M10.5.0,M3.5.0' timezone becomes 'EST'.
I was able to reproduce this error by faking a file named
'AEST-10AEDT-11,M10.5.0,M3.5.0' in /usr/share/zoneinfo/ on Mac OS X.
(As far as I know, OSX is not that different from BSD with respect to
basic posix interfaces.)
$ cd /usr/share/zoneinfo/
$ sudo cp EST AEST-10AEDT-11,M10.5.0,M3.5.0
Is it possible that the buildbot has such a file? What I find strange
is that autoconf logic tests for working tzset using exactly the same
TZ spec:
"""
 putenv("TZ=AEST-10AEDT-11,M10.5.0,M3.5.0");
 tzset();
 if (localtime(&groundhogday)->tm_hour != 11)
 exit(1);
#if HAVE_TZNAME
 if (strcmp(tzname[0], "AEST") || strcmp(tzname[1], "AEDT"))
 exit(1);
#endif
""" See 'configure' script.
In other words, if TZ=AEST-10AEDT-11,M10.5.0,M3.5.0 breaks tzset, this
should be detected at the configure stage and the tzset tests should
be skipped. Is there a way to force configure run on the bot?

Issue #13313 has been marked as a duplicate of this issue. Interesting message from flox:
"Maybe it is related.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=93810
Ambiguous timezone names (AEST vs EST)"

> Is there a way to force configure run on the bot?
./configure is run for each build of each buildbot.

I don't see this issue as a bug in Python, but just that the timezone database is different on some OSes. Can't we just accept both names, AEST and EST? Attached patch changes test_time to tolerate EST name for 'AEST-10AEDT-11,M10.5.0,M3.5.0' ("Victoria") time zone.

Alex ? Florent ?

New changeset c143e66e5efe by Victor Stinner in branch '3.2':
Issue #11886: workaround an OS bug (time zone data) in test_time
http://hg.python.org/cpython/rev/c143e66e5efe
New changeset c7638be1e430 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #11886: workaround an OS bug (time zone data) in test_time
http://hg.python.org/cpython/rev/c7638be1e430
New changeset 2bca2cee79a1 by Victor Stinner in branch '2.7':
Issue #11886: workaround an OS bug (time zone data) in test_time
http://hg.python.org/cpython/rev/2bca2cee79a1 

The FreeBSD 7.2 3.x buildbot is green.

thank you for this fix.
I agree a posteriori.

New changeset e37a7dc8944e by Victor Stinner in branch 'default':
Issue #11886: Fix also test_time for the non-DST timezone name (EST/AEST)
http://hg.python.org/cpython/rev/e37a7dc8944e 

Hum, it's still not ok:
======================================================================
FAIL: test_tzset (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_time.py", line 264, in test_tzset
 self.assertEqual(time.timezone, -36000)
AssertionError: 18000 != -36000

Another failure on a 2.7 FreeBSD buildbot:
"""
test test_time failed -- Traceback (most recent call last):
 File "/usr/home/db3l/buildarea/2.7.bolen-freebsd7/build/Lib/test/test_time.py", line 193, in test_tzset
 self.assertTrue(time.tzname[1] == 'AEDT', str(time.tzname[1]))
AssertionError: EDT
"""
http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 7.2 2.7/builds/859/steps/test/logs/stdio

What is the status of this issue? Was the failure reproduced recently?

Can this be closed as "out of date"?