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