Okay, I will proceed using the hypothesis that the problem is in the python time module and not in adodbapi, and that a fix is unimportant. The workaround is simple: do nothing! Adodbapi will use datetime.datetime by default. Only if you explicitly ask it to switch over to the old python time format will it actually use this convertion, so only antipodeans actually asking to use the obsolete time encoding are affected. I will note this as a restriction and check in the code without attempting to fix this problem at this time. Later I'll find a fix to do this convertion without calling time.gmtime(). Intrestingly, this was also a problem in IronPython. I had to file two separate bug reports to get time.gmtime working there. -- Vernon
On Thu, Feb 5, 2009 at 5:14 AM, Mark Hammond <[email protected]>wrote: > On 5/02/2009 5:10 AM, Vernon Cole wrote: > >> Okay, group, I'm opening this up for discussion... >> >> Is my routine wrong, or is the test flawed? >> >> This test works fine at my house, U.S. Mountain Standard Time. >> When I change my Windows time zone to Brisbane, it fails here like it >> does for Mark. >> > > > I'm starting to think the Python time module is as badly broken as > pywin32's time object :) This blog entry has some insight and I expect > Windows works exactly the same as described for Linux (ie, incorrectly in > the southern hemisphere). I expect win32timezone will be able to help, but > I'm out of time for now... > > > http://blogs.gnome.org/jamesh/2006/12/31/python-timetimezone-timealtzone-edge-case/ > > Cheers, > > Mark >
_______________________________________________ python-win32 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-win32
