hi,
i finally worked out what was causing the timezone problem. all of the
affected machines had a recent version of cygwin installed which sets the TZ
environment variable using zoneinfo names such as "Australia/Sydney". the
unaffected machine had an older version of cygwin which doesn't set the TZ
environment variable.
windows doesn't understand this notation and so interprets it using its own
rules. it saw "Aus" as the three-letter code for the standard timezone.
there was no +|- offset so it saw that as meaning UTC. it saw the next three
letters, "tra" as the three-letter code for the daylight savings timezone.
presumably "Aus" and "tra" mean nothing as timezone codes but it ended up
interpreting "Australia/Sydney" as if it were GMT+0100 (i.e. GMT but with
daylight savings in effect).
this explains the clock seeming to jump back and forth 9 hours several times
a day. the correct times were from python programs that weren't invoked via
cygwin and the incorrect times were from python programs that were invoked
via cygwin.
the solution was to place the following code before the first import
of the time or datetime modules:
# Note: We need to unset the TZ environment variable on Windows which is set
# by Cygwin using the UNIX naming convention (e.g. "Australia/Sydney") as
# this will be interpreted by the underlying Windows system using a
# completely different specification language (e.g. "EST+10:00EDT") thus
# creating timezone havoc. Leaving it empty results in the local timezone
# being used which is what we want. Also note that we need to do this before
# the time or datetime modules have been imported or it has no effect.
import sys, os
if sys.platform == 'win32':
_tz = os.getenv('TZ')
if _tz is not None and '/' in _tz:
os.unsetenv('TZ')
removing the TZ environment variable entirely wasn't an option as it is needed
by cygwin programs such as ls.
cheers,
raf
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
