This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, vstinner
Date 2011-04-20.19:31:11
SpamBayes Score 5.3548465e-05
Marked as misclassified No
Message-id <BANLkTi=Oia0wp0+i7m-FFj7DJbtbyP_Zvw@mail.gmail.com>
In-reply-to <1303307593.46.0.897474878267.issue11886@psf.upfronthosting.co.za>
Content
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?
History
Date User Action Args
2011-04-20 19:31:12belopolskysetrecipients: + belopolsky, vstinner
2011-04-20 19:31:11belopolskylinkissue11886 messages
2011-04-20 19:31:11belopolskycreate