[python-win32] [pywin32-checkins] py3k status

[Vernon Cole]

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 <skippy.hammond at gmail.com>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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20090205/18434b41/attachment.htm>