pywin32-bugs Mailing List for Python for Windows Extensions (Page 11)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-bugs — Automated tracker notifications (not for bug reports!)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
| 2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
| 2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
| 2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
| 2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
| 2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
| 2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
| 2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
| 2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2012-05-17 11:52:05
|
Bugs item #3527563, was opened at 2012-05-17 03:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3527563&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Whitley (robert-whitley) Assigned to: Nobody/Anonymous (nobody) Summary: dll's in wrong folder after installation Initial Comment: Using the installer for build 216 and 217 I had an error at the end which I've attached to this bug report. Win32com didn't import properly. The reason for this is that three dll's were in the wrong folder. * pywintypes26 * pythoncomloader26 * pythoncom26 They needed to be moved to win32 folder. This problem was reported on stack overflow nearly a year ago and the fix is still the same. http://stackoverflow.com/questions/7238403/import-win32api-error-in-python-2-6 I use Python 2.6 32-bit version on Windows 7 64-bit version. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2012-05-17 04:52 Message: The install script should copy them there (or to system32) - I expect that error is the problem. When exactly during the install process does this happen - right at the end? Is this reproducible - ie, can you uninstall then reinstall and see the same issue? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3527563&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-17 10:54:15
|
Bugs item #3527563, was opened at 2012-05-17 03:54 Message generated for change (Tracker Item Submitted) made by robert-whitley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3527563&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Whitley (robert-whitley) Assigned to: Nobody/Anonymous (nobody) Summary: dll's in wrong folder after installation Initial Comment: Using the installer for build 216 and 217 I had an error at the end which I've attached to this bug report. Win32com didn't import properly. The reason for this is that three dll's were in the wrong folder. * pywintypes26 * pythoncomloader26 * pythoncom26 They needed to be moved to win32 folder. This problem was reported on stack overflow nearly a year ago and the fix is still the same. http://stackoverflow.com/questions/7238403/import-win32api-error-in-python-2-6 I use Python 2.6 32-bit version on Windows 7 64-bit version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3527563&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-16 03:40:01
|
Bugs item #3476736, was opened at 2012-01-20 12:08 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3476736&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Prasanna (prapancham) Assigned to: Nobody/Anonymous (nobody) Summary: Install error in pywin32-216.win32-py2.6 Initial Comment: Hi, I am getting following error when trying to install pywin32-216.win32-py2.6 Traceback (most recent call last): File "<string>", line 604, in <module> File "<string>", line 314, in install File "<string>", line 152, in LoadSystemModule ImportError: DLL load failed: The specified module could not be found. I am on Win7 Enterprise 64 bit. First I installed the following: VC++ 2008 Redistributable -x86 9.0.21022 VC++ 2010 x64 Redistributable - 10.0.30319 Then I installed Python 2.6 ( I need to use python 2.6 ONLY) Then I am trying to install the above. But it fails. Please advise. regards, prasanna. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2012-05-15 20:40 Message: Should be fixed in build 217. ---------------------------------------------------------------------- Comment By: openhatch (openhatch) Date: 2012-05-15 19:25 Message: I got the same error, and this fix worked for me, installing on windows 7: 1. extract the installer file to a directory using the free 7zip (or similar) program 2. Copy everything in the PLATLIB directory to C:\Python26\Lib\site-packages 3. open a command prompt to the SCRIPT directory and type: python pywin32_postinstall.py -install You must have Python already installed (perhaps obviously) and in your windows PATH environment variable for this to work. You can also try the testall script in that directory, though for me it hung and I was able to import pywin32 modules from the Python IDLE just fine. From looking around the web for solutions to this error, it seems the cause may be a script not finding a dll file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3476736&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-16 02:25:23
|
Bugs item #3476736, was opened at 2012-01-20 12:08 Message generated for change (Comment added) made by openhatch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3476736&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Prasanna (prapancham) Assigned to: Nobody/Anonymous (nobody) Summary: Install error in pywin32-216.win32-py2.6 Initial Comment: Hi, I am getting following error when trying to install pywin32-216.win32-py2.6 Traceback (most recent call last): File "<string>", line 604, in <module> File "<string>", line 314, in install File "<string>", line 152, in LoadSystemModule ImportError: DLL load failed: The specified module could not be found. I am on Win7 Enterprise 64 bit. First I installed the following: VC++ 2008 Redistributable -x86 9.0.21022 VC++ 2010 x64 Redistributable - 10.0.30319 Then I installed Python 2.6 ( I need to use python 2.6 ONLY) Then I am trying to install the above. But it fails. Please advise. regards, prasanna. ---------------------------------------------------------------------- Comment By: openhatch (openhatch) Date: 2012-05-15 19:25 Message: I got the same error, and this fix worked for me, installing on windows 7: 1. extract the installer file to a directory using the free 7zip (or similar) program 2. Copy everything in the PLATLIB directory to C:\Python26\Lib\site-packages 3. open a command prompt to the SCRIPT directory and type: python pywin32_postinstall.py -install You must have Python already installed (perhaps obviously) and in your windows PATH environment variable for this to work. You can also try the testall script in that directory, though for me it hung and I was able to import pywin32 modules from the Python IDLE just fine. From looking around the web for solutions to this error, it seems the cause may be a script not finding a dll file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3476736&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-16 00:34:58
|
Bugs item #3525912, was opened at 2012-05-11 10:37 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Fox (mike_fox) Assigned to: Nobody/Anonymous (nobody) Summary: InvokeTypes error using win32com v2.17 Initial Comment: I think we have found a bug in win32com 2.17. We are using it with Python 2.7.2. We are calling a proprietary DLL named PATE, which provides APIs to a database named Enovia from the Dassault corporation. The Enovia client is linked to a CAD program named CATIA so we must conjure objects of both CATIA and Enovia as shown in the code snippet below. The strApplicationID is a password administered by my company and has nothing to do with the PATE DLL itself. Rather, PATE should pass the strApplicationID to the Enovia server, which should authenticate the session. ==================================================================== import win32com.client, win32com.client.gencache, win32com.client.selecttlb strPATECLSID = '{9BB3CB79-7098-47D0-83A2-F8F56D236DC8}' strPATEclassCLSID = '{9A1F3C8E-46B7-4CFA-A820-E4256ECD53B5}' self.objCATIA = win32com.client.GetActiveObject('CATIA.Application') win32com.client.gencache.EnsureModule(strPATECLSID, 0, 0, 0) self.objBase= win32com.client.gencache.GetClassForCLSID(strPATEclassCLSID) self.__objPATECOM = self.objBase(self.objCATIA) strApplicationID = <secret> try: self.__objPATECOM.SetApplicationID(strApplicationID) except (pywintypes.com_error), _e: print "Connection error: %s" %(_e) return False ==================================================================== When we use win32com 2.16 the code above works fine but when we use win32com 2.17 it throws the error message shown below. File testKBE_PATECAKE.py, line 367 in ConnectToENOVIA self.__objPATECOM.SetApplicationID(strApplicationID) File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79 -7098-47D0-83A2-F8 F56D236DC8x0x0x0.py", line 457 in SetApplicationID return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0), ((16396, 1),) , iAID File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 516 in __getattr__ raise AttributeError("%s.%s" % (self._username_, attr)) AttributeEror: CATIA.Application.InvokeTypes ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2012-05-15 17:34 Message: Can you please modify your test code to add: print self.objCATIA After creating it, and tell me what it prints in both the failing and working cases? ---------------------------------------------------------------------- Comment By: Mike Fox (mike_fox) Date: 2012-05-15 17:32 Message: To Mark Hammond: I don't think the problem is caused by a pre-existing wrapper in the gen_py folder as you suggested in your comment. When I uninstalled version 2.17 of pywin32 and installed version 2.16 on the same PC (with the contents of the gen_py folder unchanged) I was able to call the SetApplicationID method without it throwing an error. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2012-05-11 19:51 Message: I suspect the problem is that previously you have makepy support generated for the 'CATIA.Application' object which should make things work. The problem is that when you do: self.__objPATECOM = self.objBase(self.objCATIA) The DispatchBaseClass.__init__ function in win32com\client\__init__.py checks to see if the object is itself a makepy generated object and will work correctly if it is. Even though, this really is a bug as we should handle that situation. A fix would probably be to change the line in DispatchBaseClass.__init__ from: elif isinstance(oobj, DispatchBaseClass): to elif hasattr(oobj, "_oleobj_"): ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-16 00:32:40
|
Bugs item #3525912, was opened at 2012-05-11 10:37 Message generated for change (Comment added) made by mike_fox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Fox (mike_fox) Assigned to: Nobody/Anonymous (nobody) Summary: InvokeTypes error using win32com v2.17 Initial Comment: I think we have found a bug in win32com 2.17. We are using it with Python 2.7.2. We are calling a proprietary DLL named PATE, which provides APIs to a database named Enovia from the Dassault corporation. The Enovia client is linked to a CAD program named CATIA so we must conjure objects of both CATIA and Enovia as shown in the code snippet below. The strApplicationID is a password administered by my company and has nothing to do with the PATE DLL itself. Rather, PATE should pass the strApplicationID to the Enovia server, which should authenticate the session. ==================================================================== import win32com.client, win32com.client.gencache, win32com.client.selecttlb strPATECLSID = '{9BB3CB79-7098-47D0-83A2-F8F56D236DC8}' strPATEclassCLSID = '{9A1F3C8E-46B7-4CFA-A820-E4256ECD53B5}' self.objCATIA = win32com.client.GetActiveObject('CATIA.Application') win32com.client.gencache.EnsureModule(strPATECLSID, 0, 0, 0) self.objBase= win32com.client.gencache.GetClassForCLSID(strPATEclassCLSID) self.__objPATECOM = self.objBase(self.objCATIA) strApplicationID = <secret> try: self.__objPATECOM.SetApplicationID(strApplicationID) except (pywintypes.com_error), _e: print "Connection error: %s" %(_e) return False ==================================================================== When we use win32com 2.16 the code above works fine but when we use win32com 2.17 it throws the error message shown below. File testKBE_PATECAKE.py, line 367 in ConnectToENOVIA self.__objPATECOM.SetApplicationID(strApplicationID) File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79 -7098-47D0-83A2-F8 F56D236DC8x0x0x0.py", line 457 in SetApplicationID return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0), ((16396, 1),) , iAID File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 516 in __getattr__ raise AttributeError("%s.%s" % (self._username_, attr)) AttributeEror: CATIA.Application.InvokeTypes ---------------------------------------------------------------------- >Comment By: Mike Fox (mike_fox) Date: 2012-05-15 17:32 Message: To Mark Hammond: I don't think the problem is caused by a pre-existing wrapper in the gen_py folder as you suggested in your comment. When I uninstalled version 2.17 of pywin32 and installed version 2.16 on the same PC (with the contents of the gen_py folder unchanged) I was able to call the SetApplicationID method without it throwing an error. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2012-05-11 19:51 Message: I suspect the problem is that previously you have makepy support generated for the 'CATIA.Application' object which should make things work. The problem is that when you do: self.__objPATECOM = self.objBase(self.objCATIA) The DispatchBaseClass.__init__ function in win32com\client\__init__.py checks to see if the object is itself a makepy generated object and will work correctly if it is. Even though, this really is a bug as we should handle that situation. A fix would probably be to change the line in DispatchBaseClass.__init__ from: elif isinstance(oobj, DispatchBaseClass): to elif hasattr(oobj, "_oleobj_"): ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-13 21:53:31
|
Bugs item #3525567, was opened at 2012-05-10 09:19 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525567&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: Fix for 3524786 breaks None-ambiguous conversions Initial Comment: I seem to be causing you lots of problems.... :( The fix for 3524786 has introduced new issues. This example shows a none-ambiguous conversion. The timestamps are in UTC, and therefore do have a correct conversion that is not ambiguous. I dont think raising an exception is going to help here. The script should be run with the PC in the Pacific Time Zone so localtime() can be used for comparison. It should show local times of 2:00 AM (STD), 1:00 AM (STD), 1:00 AM (DST) I am going to suggest removing the exception. The ambiguous issue is when converting from localtimes to UTC or another timezone. I am not really sure how it should be fixed. The only possible solution is to be able to tell the function it is 1:30 in DST or STD. but I dont know how this could be implemented as datetime does not have this. Perhaps it should just be documented as an ambiguity. Anyway, here is the script showing the problem. >>> import win32timezone >>> from datetime import datetime >>> import time >>> ... PST = win32timezone.TimeZoneInfo('Pacific Standard Time') >>> >>> print datetime.fromtimestamp(1320573600, PST) 2011-11-06 02:00:00-08:00 >>> print datetime.fromtimestamp(1320570000, PST) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 635, in utcoffset return -winInfo.bias + self.dst(dt) File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 641, in dst if not self.fixedStandardTime and self._inDaylightSavings(dt): File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 664, in _inDaylightSavings raise AmbiguousTimeError(dt) win32timezone.AmbiguousTimeError: 2011-11-06 01:00:00 >>> print datetime.fromtimestamp(1320566400, PST) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 635, in utcoffset return -winInfo.bias + self.dst(dt) File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 641, in dst if not self.fixedStandardTime and self._inDaylightSavings(dt): File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 664, in _inDaylightSavings raise AmbiguousTimeError(dt) win32timezone.AmbiguousTimeError: 2011-11-06 01:00:00 >>> >>> print time.strftime('%c', time.localtime(1320573600)) 11/06/11 02:00:00 >>> print time.strftime('%c', time.localtime(1320570000)) 11/06/11 01:00:00 >>> print time.strftime('%c', time.localtime(1320566400)) 11/06/11 01:00:00 >>> ---------------------------------------------------------------------- >Comment By: Jason R. Coombs (jaraco) Date: 2012-05-13 14:53 Message: Thanks. I've backed out the ambiguous timezone detection, so the code is using the earlier code against which you tested. Now to figure out how to determine the correct time zone for timestamps. It's not at all clear from the datetime documentation what needs to be done to produce a proper result in the case of the timestamp. Looking at another implementation, pytz, I see that it actually uses a different timezone object than the one that was passed in when it processes the fromtimestamp, and the tzinfo objects themselves have daylight savings time awareness: >>> import pytz >>> PST = pytz.timezone('US/Pacific') >>> PST <DstTzInfo 'US/Pacific' PST-1 day, 16:00:00 STD> >>> import datetime >>> datetime.datetime.fromtimestamp(1320566400, PST) datetime.datetime(2011, 11, 6, 1, 0, tzinfo=<DstTzInfo 'US/Pacific' PDT-1 day, 17:00:00 DST>) >>> _.tzinfo <DstTzInfo 'US/Pacific' PDT-1 day, 17:00:00 DST> This finding makes me think that the proper implementation of a timezone object on Python is far more complicated than the datetime docs suggest it should be. I plan to revisit this at some point. ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-05-10 09:29 Message: Ok, that is much better. There is still one issue, datetime is showing the offset as -08:00 for the last timestamp, and it should be -07:00. But the hour is correct now. >>> import win32timezone >>> from datetime import datetime >>> import time >>> ... PST = win32timezone.TimeZoneInfo('Pacific Standard Time') >>> >>> print datetime.fromtimestamp(1320573600, PST) 2011-11-06 02:00:00-08:00 >>> print datetime.fromtimestamp(1320570000, PST) 2011-11-06 01:00:00-08:00 >>> print datetime.fromtimestamp(1320566400, PST) 2011-11-06 01:00:00-08:00 >>> >>> print time.strftime('%c', time.localtime(1320573600)) 11/06/11 02:00:00 >>> print time.strftime('%c', time.localtime(1320570000)) 11/06/11 01:00:00 >>> print time.strftime('%c', time.localtime(1320566400)) 11/06/11 01:00:00 >>> ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-05-10 09:22 Message: I was afraid we might encounter something like this. In that case, would you try the parent revision, which doesn't add the ambiguous exception? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525567&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-12 02:51:57
|
Bugs item #3525912, was opened at 2012-05-11 10:37 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Fox (mike_fox) Assigned to: Nobody/Anonymous (nobody) Summary: InvokeTypes error using win32com v2.17 Initial Comment: I think we have found a bug in win32com 2.17. We are using it with Python 2.7.2. We are calling a proprietary DLL named PATE, which provides APIs to a database named Enovia from the Dassault corporation. The Enovia client is linked to a CAD program named CATIA so we must conjure objects of both CATIA and Enovia as shown in the code snippet below. The strApplicationID is a password administered by my company and has nothing to do with the PATE DLL itself. Rather, PATE should pass the strApplicationID to the Enovia server, which should authenticate the session. ==================================================================== import win32com.client, win32com.client.gencache, win32com.client.selecttlb strPATECLSID = '{9BB3CB79-7098-47D0-83A2-F8F56D236DC8}' strPATEclassCLSID = '{9A1F3C8E-46B7-4CFA-A820-E4256ECD53B5}' self.objCATIA = win32com.client.GetActiveObject('CATIA.Application') win32com.client.gencache.EnsureModule(strPATECLSID, 0, 0, 0) self.objBase= win32com.client.gencache.GetClassForCLSID(strPATEclassCLSID) self.__objPATECOM = self.objBase(self.objCATIA) strApplicationID = <secret> try: self.__objPATECOM.SetApplicationID(strApplicationID) except (pywintypes.com_error), _e: print "Connection error: %s" %(_e) return False ==================================================================== When we use win32com 2.16 the code above works fine but when we use win32com 2.17 it throws the error message shown below. File testKBE_PATECAKE.py, line 367 in ConnectToENOVIA self.__objPATECOM.SetApplicationID(strApplicationID) File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79 -7098-47D0-83A2-F8 F56D236DC8x0x0x0.py", line 457 in SetApplicationID return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0), ((16396, 1),) , iAID File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 516 in __getattr__ raise AttributeError("%s.%s" % (self._username_, attr)) AttributeEror: CATIA.Application.InvokeTypes ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2012-05-11 19:51 Message: I suspect the problem is that previously you have makepy support generated for the 'CATIA.Application' object which should make things work. The problem is that when you do: self.__objPATECOM = self.objBase(self.objCATIA) The DispatchBaseClass.__init__ function in win32com\client\__init__.py checks to see if the object is itself a makepy generated object and will work correctly if it is. Even though, this really is a bug as we should handle that situation. A fix would probably be to change the line in DispatchBaseClass.__init__ from: elif isinstance(oobj, DispatchBaseClass): to elif hasattr(oobj, "_oleobj_"): ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-11 17:37:23
|
Bugs item #3525912, was opened at 2012-05-11 10:37 Message generated for change (Tracker Item Submitted) made by mike_fox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Fox (mike_fox) Assigned to: Nobody/Anonymous (nobody) Summary: InvokeTypes error using win32com v2.17 Initial Comment: I think we have found a bug in win32com 2.17. We are using it with Python 2.7.2. We are calling a proprietary DLL named PATE, which provides APIs to a database named Enovia from the Dassault corporation. The Enovia client is linked to a CAD program named CATIA so we must conjure objects of both CATIA and Enovia as shown in the code snippet below. The strApplicationID is a password administered by my company and has nothing to do with the PATE DLL itself. Rather, PATE should pass the strApplicationID to the Enovia server, which should authenticate the session. ==================================================================== import win32com.client, win32com.client.gencache, win32com.client.selecttlb strPATECLSID = '{9BB3CB79-7098-47D0-83A2-F8F56D236DC8}' strPATEclassCLSID = '{9A1F3C8E-46B7-4CFA-A820-E4256ECD53B5}' self.objCATIA = win32com.client.GetActiveObject('CATIA.Application') win32com.client.gencache.EnsureModule(strPATECLSID, 0, 0, 0) self.objBase= win32com.client.gencache.GetClassForCLSID(strPATEclassCLSID) self.__objPATECOM = self.objBase(self.objCATIA) strApplicationID = <secret> try: self.__objPATECOM.SetApplicationID(strApplicationID) except (pywintypes.com_error), _e: print "Connection error: %s" %(_e) return False ==================================================================== When we use win32com 2.16 the code above works fine but when we use win32com 2.17 it throws the error message shown below. File testKBE_PATECAKE.py, line 367 in ConnectToENOVIA self.__objPATECOM.SetApplicationID(strApplicationID) File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79 -7098-47D0-83A2-F8 F56D236DC8x0x0x0.py", line 457 in SetApplicationID return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0), ((16396, 1),) , iAID File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 516 in __getattr__ raise AttributeError("%s.%s" % (self._username_, attr)) AttributeEror: CATIA.Application.InvokeTypes ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-10 16:29:39
|
Bugs item #3525567, was opened at 2012-05-10 09:19 Message generated for change (Comment added) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525567&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: Fix for 3524786 breaks None-ambiguous conversions Initial Comment: I seem to be causing you lots of problems.... :( The fix for 3524786 has introduced new issues. This example shows a none-ambiguous conversion. The timestamps are in UTC, and therefore do have a correct conversion that is not ambiguous. I dont think raising an exception is going to help here. The script should be run with the PC in the Pacific Time Zone so localtime() can be used for comparison. It should show local times of 2:00 AM (STD), 1:00 AM (STD), 1:00 AM (DST) I am going to suggest removing the exception. The ambiguous issue is when converting from localtimes to UTC or another timezone. I am not really sure how it should be fixed. The only possible solution is to be able to tell the function it is 1:30 in DST or STD. but I dont know how this could be implemented as datetime does not have this. Perhaps it should just be documented as an ambiguity. Anyway, here is the script showing the problem. >>> import win32timezone >>> from datetime import datetime >>> import time >>> ... PST = win32timezone.TimeZoneInfo('Pacific Standard Time') >>> >>> print datetime.fromtimestamp(1320573600, PST) 2011-11-06 02:00:00-08:00 >>> print datetime.fromtimestamp(1320570000, PST) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 635, in utcoffset return -winInfo.bias + self.dst(dt) File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 641, in dst if not self.fixedStandardTime and self._inDaylightSavings(dt): File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 664, in _inDaylightSavings raise AmbiguousTimeError(dt) win32timezone.AmbiguousTimeError: 2011-11-06 01:00:00 >>> print datetime.fromtimestamp(1320566400, PST) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 635, in utcoffset return -winInfo.bias + self.dst(dt) File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 641, in dst if not self.fixedStandardTime and self._inDaylightSavings(dt): File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 664, in _inDaylightSavings raise AmbiguousTimeError(dt) win32timezone.AmbiguousTimeError: 2011-11-06 01:00:00 >>> >>> print time.strftime('%c', time.localtime(1320573600)) 11/06/11 02:00:00 >>> print time.strftime('%c', time.localtime(1320570000)) 11/06/11 01:00:00 >>> print time.strftime('%c', time.localtime(1320566400)) 11/06/11 01:00:00 >>> ---------------------------------------------------------------------- >Comment By: Brian Matthews (bmatthews27) Date: 2012-05-10 09:29 Message: Ok, that is much better. There is still one issue, datetime is showing the offset as -08:00 for the last timestamp, and it should be -07:00. But the hour is correct now. >>> import win32timezone >>> from datetime import datetime >>> import time >>> ... PST = win32timezone.TimeZoneInfo('Pacific Standard Time') >>> >>> print datetime.fromtimestamp(1320573600, PST) 2011-11-06 02:00:00-08:00 >>> print datetime.fromtimestamp(1320570000, PST) 2011-11-06 01:00:00-08:00 >>> print datetime.fromtimestamp(1320566400, PST) 2011-11-06 01:00:00-08:00 >>> >>> print time.strftime('%c', time.localtime(1320573600)) 11/06/11 02:00:00 >>> print time.strftime('%c', time.localtime(1320570000)) 11/06/11 01:00:00 >>> print time.strftime('%c', time.localtime(1320566400)) 11/06/11 01:00:00 >>> ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-05-10 09:22 Message: I was afraid we might encounter something like this. In that case, would you try the parent revision, which doesn't add the ambiguous exception? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525567&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-10 16:22:06
|
Bugs item #3525567, was opened at 2012-05-10 09:19 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525567&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: Fix for 3524786 breaks None-ambiguous conversions Initial Comment: I seem to be causing you lots of problems.... :( The fix for 3524786 has introduced new issues. This example shows a none-ambiguous conversion. The timestamps are in UTC, and therefore do have a correct conversion that is not ambiguous. I dont think raising an exception is going to help here. The script should be run with the PC in the Pacific Time Zone so localtime() can be used for comparison. It should show local times of 2:00 AM (STD), 1:00 AM (STD), 1:00 AM (DST) I am going to suggest removing the exception. The ambiguous issue is when converting from localtimes to UTC or another timezone. I am not really sure how it should be fixed. The only possible solution is to be able to tell the function it is 1:30 in DST or STD. but I dont know how this could be implemented as datetime does not have this. Perhaps it should just be documented as an ambiguity. Anyway, here is the script showing the problem. >>> import win32timezone >>> from datetime import datetime >>> import time >>> ... PST = win32timezone.TimeZoneInfo('Pacific Standard Time') >>> >>> print datetime.fromtimestamp(1320573600, PST) 2011-11-06 02:00:00-08:00 >>> print datetime.fromtimestamp(1320570000, PST) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 635, in utcoffset return -winInfo.bias + self.dst(dt) File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 641, in dst if not self.fixedStandardTime and self._inDaylightSavings(dt): File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 664, in _inDaylightSavings raise AmbiguousTimeError(dt) win32timezone.AmbiguousTimeError: 2011-11-06 01:00:00 >>> print datetime.fromtimestamp(1320566400, PST) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 635, in utcoffset return -winInfo.bias + self.dst(dt) File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 641, in dst if not self.fixedStandardTime and self._inDaylightSavings(dt): File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 664, in _inDaylightSavings raise AmbiguousTimeError(dt) win32timezone.AmbiguousTimeError: 2011-11-06 01:00:00 >>> >>> print time.strftime('%c', time.localtime(1320573600)) 11/06/11 02:00:00 >>> print time.strftime('%c', time.localtime(1320570000)) 11/06/11 01:00:00 >>> print time.strftime('%c', time.localtime(1320566400)) 11/06/11 01:00:00 >>> ---------------------------------------------------------------------- >Comment By: Jason R. Coombs (jaraco) Date: 2012-05-10 09:22 Message: I was afraid we might encounter something like this. In that case, would you try the parent revision, which doesn't add the ambiguous exception? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525567&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-10 16:19:44
|
Bugs item #3525567, was opened at 2012-05-10 09:19 Message generated for change (Tracker Item Submitted) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525567&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: Fix for 3524786 breaks None-ambiguous conversions Initial Comment: I seem to be causing you lots of problems.... :( The fix for 3524786 has introduced new issues. This example shows a none-ambiguous conversion. The timestamps are in UTC, and therefore do have a correct conversion that is not ambiguous. I dont think raising an exception is going to help here. The script should be run with the PC in the Pacific Time Zone so localtime() can be used for comparison. It should show local times of 2:00 AM (STD), 1:00 AM (STD), 1:00 AM (DST) I am going to suggest removing the exception. The ambiguous issue is when converting from localtimes to UTC or another timezone. I am not really sure how it should be fixed. The only possible solution is to be able to tell the function it is 1:30 in DST or STD. but I dont know how this could be implemented as datetime does not have this. Perhaps it should just be documented as an ambiguity. Anyway, here is the script showing the problem. >>> import win32timezone >>> from datetime import datetime >>> import time >>> ... PST = win32timezone.TimeZoneInfo('Pacific Standard Time') >>> >>> print datetime.fromtimestamp(1320573600, PST) 2011-11-06 02:00:00-08:00 >>> print datetime.fromtimestamp(1320570000, PST) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 635, in utcoffset return -winInfo.bias + self.dst(dt) File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 641, in dst if not self.fixedStandardTime and self._inDaylightSavings(dt): File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 664, in _inDaylightSavings raise AmbiguousTimeError(dt) win32timezone.AmbiguousTimeError: 2011-11-06 01:00:00 >>> print datetime.fromtimestamp(1320566400, PST) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 635, in utcoffset return -winInfo.bias + self.dst(dt) File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 641, in dst if not self.fixedStandardTime and self._inDaylightSavings(dt): File "C:\Python27\lib\site-packages\win32\lib\win32timezone.py", line 664, in _inDaylightSavings raise AmbiguousTimeError(dt) win32timezone.AmbiguousTimeError: 2011-11-06 01:00:00 >>> >>> print time.strftime('%c', time.localtime(1320573600)) 11/06/11 02:00:00 >>> print time.strftime('%c', time.localtime(1320570000)) 11/06/11 01:00:00 >>> print time.strftime('%c', time.localtime(1320566400)) 11/06/11 01:00:00 >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525567&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-10 13:18:12
|
Bugs item #3524786, was opened at 2012-05-08 09:34 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3524786&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: Conversion of UTC timestamp to localtime is wrong at STD/DST Initial Comment: I am not sure if this error is in TimeZoneInfo or datetime. I am running my PC in Pacific time, so I have a way to easily check the results. The script below converts UTC timestamps into a datetime in the Pacific time zone. The result for PST 2:00 AM on 2011-11-06 is wrong. Doing the same conversion using localtime() is correct. During the ambiguous localtime hour on 6-Nov, 2:00 AM should only appear once. 1:00 AM should appear twice. >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> import calendar >>> import time >>> >>> tzi = TimeZoneInfo('Pacific Standard Time') >>> tzutc = TimeZoneInfo('Coordinated Universal Time') >>> >>> def fromtimestamp_to_timetuple(timestamp): ... tm = time.gmtime(timestamp) ... tz1 = datetime(tm.tm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour, ... tm.tm_min, tm.tm_sec, tzinfo=tzutc) ... tz_time = tz1.astimezone(tzi) ... return tz_time ... >>> print fromtimestamp_to_timetuple(1320573600).timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=6, tm_hour=2, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=310, tm_isdst=0) >>> print fromtimestamp_to_timetuple(1320570000).timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=6, tm_hour=2, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=310, tm_isdst=0) >>> print fromtimestamp_to_timetuple(1320566400).timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=6, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=310, tm_isdst=1) >>> >>> print time.strftime('%c', time.localtime(1320573600)) 11/06/11 02:00:00 >>> print time.strftime('%c', time.localtime(1320570000)) 11/06/11 01:00:00 >>> print time.strftime('%c', time.localtime(1320566400)) 11/06/11 01:00:00 ---------------------------------------------------------------------- >Comment By: Jason R. Coombs (jaraco) Date: 2012-05-10 06:18 Message: I've pushed two more changesets that address this issue. Thanks again for providing a detailed report helping me create tests to capture and resolve the problem. The latest changeset also now raises an AmbiguousTimeError if .utcoffset or .dst is called for a datetime which could be either. It includes its own tests and doesn't cause any of the existing tests to fail. Please take a look at the latest revisions and please don't hesitate to let me know if you encounter any other issues. ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-05-08 09:46 Message: NOTE: This is a problem only at precisely the end of the hour. It is using the most recent patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3524786&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-08 16:46:26
|
Bugs item #3524786, was opened at 2012-05-08 09:34 Message generated for change (Comment added) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3524786&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: Conversion of UTC timestamp to localtime is wrong at STD/DST Initial Comment: I am not sure if this error is in TimeZoneInfo or datetime. I am running my PC in Pacific time, so I have a way to easily check the results. The script below converts UTC timestamps into a datetime in the Pacific time zone. The result for PST 2:00 AM on 2011-11-06 is wrong. Doing the same conversion using localtime() is correct. During the ambiguous localtime hour on 6-Nov, 2:00 AM should only appear once. 1:00 AM should appear twice. >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> import calendar >>> import time >>> >>> tzi = TimeZoneInfo('Pacific Standard Time') >>> tzutc = TimeZoneInfo('Coordinated Universal Time') >>> >>> def fromtimestamp_to_timetuple(timestamp): ... tm = time.gmtime(timestamp) ... tz1 = datetime(tm.tm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour, ... tm.tm_min, tm.tm_sec, tzinfo=tzutc) ... tz_time = tz1.astimezone(tzi) ... return tz_time ... >>> print fromtimestamp_to_timetuple(1320573600).timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=6, tm_hour=2, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=310, tm_isdst=0) >>> print fromtimestamp_to_timetuple(1320570000).timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=6, tm_hour=2, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=310, tm_isdst=0) >>> print fromtimestamp_to_timetuple(1320566400).timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=6, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=310, tm_isdst=1) >>> >>> print time.strftime('%c', time.localtime(1320573600)) 11/06/11 02:00:00 >>> print time.strftime('%c', time.localtime(1320570000)) 11/06/11 01:00:00 >>> print time.strftime('%c', time.localtime(1320566400)) 11/06/11 01:00:00 ---------------------------------------------------------------------- >Comment By: Brian Matthews (bmatthews27) Date: 2012-05-08 09:46 Message: NOTE: This is a problem only at precisely the end of the hour. It is using the most recent patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3524786&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-08 16:34:33
|
Bugs item #3524786, was opened at 2012-05-08 09:34 Message generated for change (Tracker Item Submitted) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3524786&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: Conversion of UTC timestamp to localtime is wrong at STD/DST Initial Comment: I am not sure if this error is in TimeZoneInfo or datetime. I am running my PC in Pacific time, so I have a way to easily check the results. The script below converts UTC timestamps into a datetime in the Pacific time zone. The result for PST 2:00 AM on 2011-11-06 is wrong. Doing the same conversion using localtime() is correct. During the ambiguous localtime hour on 6-Nov, 2:00 AM should only appear once. 1:00 AM should appear twice. >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> import calendar >>> import time >>> >>> tzi = TimeZoneInfo('Pacific Standard Time') >>> tzutc = TimeZoneInfo('Coordinated Universal Time') >>> >>> def fromtimestamp_to_timetuple(timestamp): ... tm = time.gmtime(timestamp) ... tz1 = datetime(tm.tm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour, ... tm.tm_min, tm.tm_sec, tzinfo=tzutc) ... tz_time = tz1.astimezone(tzi) ... return tz_time ... >>> print fromtimestamp_to_timetuple(1320573600).timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=6, tm_hour=2, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=310, tm_isdst=0) >>> print fromtimestamp_to_timetuple(1320570000).timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=6, tm_hour=2, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=310, tm_isdst=0) >>> print fromtimestamp_to_timetuple(1320566400).timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=6, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=310, tm_isdst=1) >>> >>> print time.strftime('%c', time.localtime(1320573600)) 11/06/11 02:00:00 >>> print time.strftime('%c', time.localtime(1320570000)) 11/06/11 01:00:00 >>> print time.strftime('%c', time.localtime(1320566400)) 11/06/11 01:00:00 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3524786&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-05 05:19:46
|
Bugs item #3523104, was opened at 2012-05-02 13:01 Message generated for change (Comment added) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: TimeZoneInfo does not convert timezones correctly Initial Comment: in the following example two dates are converted from Hawaii time zone to Pacific time zone. In both cases the time difference should be 3 hours. The first is correct, the second is incorrect >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> tzi = TimeZoneInfo('Hawaiian Standard Time') >>> tzs = TimeZoneInfo('Pacific Standard Time') >>> dthaw = datetime(2011, 11, 5, 15, 59, 59, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=15, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=18, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=1) >>> >>> dthaw = datetime(2011, 11, 5, 16, 0, 0, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=16, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=17, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=1) >>> ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-05-04 22:19 Message: Thanks again for your quick work! A small discrepancy. I am running my PC in Pacific time, so I have a way to check the results. The script below converts a UTC timestamp into a datetime in the Pacific time zone. The result is different for the second timestamp when doing the same thing using localtime() from win32timezone import TimeZoneInfo from datetime import datetime import calendar import time tzi = TimeZoneInfo('Pacific Standard Time') tzutc = TimeZoneInfo('Coordinated Universal Time') def fromtimestamp_to_timetuple(timestamp): tm = time.gmtime(timestamp) tz1 = datetime(tm.tm_year, tm.tm_mon, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec, tzinfo=tzutc) tz_time = tz1.astimezone(tzi) return tz_time print fromtimestamp_to_timetuple(1320573600).timetuple() print fromtimestamp_to_timetuple(1320570000).timetuple() print fromtimestamp_to_timetuple(1320566400).timetuple() print time.strftime('%c', time.localtime(1320573600)) print time.strftime('%c', time.localtime(1320570000)) print time.strftime('%c', time.localtime(1320566400)) To answer you question about the function for Naive datetime. It would be better if utcoffset() accepted a datetime that was not Naive. This example logically should show a utcoffset of -7, but it shows -8 as utcoffset ignores the tz in datetime from win32timezone import TimeZoneInfo from datetime import datetime import calendar import time tzi = TimeZoneInfo('Pacific Standard Time') tzutc = TimeZoneInfo('Coordinated Universal Time') tz_time = datetime(2011, 11, 6, 4, 0, 0, tzinfo=tzutc) tzi.utcoffset(tz_time).total_seconds()/60/60 But this is academic for me at this point, plus it might break existing code. Maybe a new function that is accepts tz-aware datetimes? ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-05-04 17:37 Message: Brian, thanks for your help and patience. The problem is fixed in 085048997feb. You want the utc offset for a utc timestamp in a specified timezone? >>> timestamp = datetime(2011, 11, 6, 4, 0, tzinfo=TimeZoneInfo.utc()) >>> dt_pac = timestamp.astimezone(TimeZoneInfo('Pacific Standard Time')) >>> dt_pac.utcoffset().total_seconds() / 3600 -7.0 Do you think win32timezone should have a single function that takes a naive timestamp in utc and a time zone name and returns the offset? Something like offset_for_utc_timestamp_in_zone(datetime, zone_name) ? ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-05-04 16:30 Message: I think the problem is that TimeZoneInof only works with Naive datetime. That is, if you pass in a datetime in UTC, the utcoffset() returns as if it were localtime. EG: from win32timezone import TimeZoneInfo from datetime import datetime import calendar import time tzi = TimeZoneInfo('Pacific Standard Time') tzutc = TimeZoneInfo('Coordinated Universal Time') tz_time = datetime(2011, 11, 6, 4, 0, 0, tzinfo=tzutc) tzi.utcoffset(tz_time).total_seconds()/60/60 shows -8:00 when it should be -7:00 because the datetime is UTC, not localtime. We have a way around this rght now by doing a 2-pass calculation tto see if we crossed the pst/dst time. win32timezone needs a method of showing the utcoffset for a utc timestamp in the specified timezone ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-05-03 05:27 Message: I've started looking into this, and I've expanded the tests you provided: http://a.libpa.st/mP7l7 According to the docs, astimezone should be converting from a very strange form (the time in UTC with the pacific time zone indicated), and fromutc should handle that correctly as long as the standard offset isn't changing on an hour-by-hour basis (which it is not for either of these time zones). http://docs.python.org/library/datetime.html#datetime.datetime.astimezone http://docs.python.org/library/datetime.html#datetime.tzinfo.fromutc I'll continue to investigate, but this is beginning to look like a bug in the datetime implementation (or at least the docs). ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-05-02 13:11 Message: This was using the patched code from #3521185 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-05 00:37:31
|
Bugs item #3523104, was opened at 2012-05-02 13:01 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: TimeZoneInfo does not convert timezones correctly Initial Comment: in the following example two dates are converted from Hawaii time zone to Pacific time zone. In both cases the time difference should be 3 hours. The first is correct, the second is incorrect >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> tzi = TimeZoneInfo('Hawaiian Standard Time') >>> tzs = TimeZoneInfo('Pacific Standard Time') >>> dthaw = datetime(2011, 11, 5, 15, 59, 59, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=15, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=18, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=1) >>> >>> dthaw = datetime(2011, 11, 5, 16, 0, 0, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=16, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=17, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=1) >>> ---------------------------------------------------------------------- >Comment By: Jason R. Coombs (jaraco) Date: 2012-05-04 17:37 Message: Brian, thanks for your help and patience. The problem is fixed in 085048997feb. You want the utc offset for a utc timestamp in a specified timezone? >>> timestamp = datetime(2011, 11, 6, 4, 0, tzinfo=TimeZoneInfo.utc()) >>> dt_pac = timestamp.astimezone(TimeZoneInfo('Pacific Standard Time')) >>> dt_pac.utcoffset().total_seconds() / 3600 -7.0 Do you think win32timezone should have a single function that takes a naive timestamp in utc and a time zone name and returns the offset? Something like offset_for_utc_timestamp_in_zone(datetime, zone_name) ? ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-05-04 16:30 Message: I think the problem is that TimeZoneInof only works with Naive datetime. That is, if you pass in a datetime in UTC, the utcoffset() returns as if it were localtime. EG: from win32timezone import TimeZoneInfo from datetime import datetime import calendar import time tzi = TimeZoneInfo('Pacific Standard Time') tzutc = TimeZoneInfo('Coordinated Universal Time') tz_time = datetime(2011, 11, 6, 4, 0, 0, tzinfo=tzutc) tzi.utcoffset(tz_time).total_seconds()/60/60 shows -8:00 when it should be -7:00 because the datetime is UTC, not localtime. We have a way around this rght now by doing a 2-pass calculation tto see if we crossed the pst/dst time. win32timezone needs a method of showing the utcoffset for a utc timestamp in the specified timezone ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-05-03 05:27 Message: I've started looking into this, and I've expanded the tests you provided: http://a.libpa.st/mP7l7 According to the docs, astimezone should be converting from a very strange form (the time in UTC with the pacific time zone indicated), and fromutc should handle that correctly as long as the standard offset isn't changing on an hour-by-hour basis (which it is not for either of these time zones). http://docs.python.org/library/datetime.html#datetime.datetime.astimezone http://docs.python.org/library/datetime.html#datetime.tzinfo.fromutc I'll continue to investigate, but this is beginning to look like a bug in the datetime implementation (or at least the docs). ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-05-02 13:11 Message: This was using the patched code from #3521185 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-04 23:30:15
|
Bugs item #3523104, was opened at 2012-05-02 13:01 Message generated for change (Comment added) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: TimeZoneInfo does not convert timezones correctly Initial Comment: in the following example two dates are converted from Hawaii time zone to Pacific time zone. In both cases the time difference should be 3 hours. The first is correct, the second is incorrect >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> tzi = TimeZoneInfo('Hawaiian Standard Time') >>> tzs = TimeZoneInfo('Pacific Standard Time') >>> dthaw = datetime(2011, 11, 5, 15, 59, 59, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=15, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=18, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=1) >>> >>> dthaw = datetime(2011, 11, 5, 16, 0, 0, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=16, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=17, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=1) >>> ---------------------------------------------------------------------- >Comment By: Brian Matthews (bmatthews27) Date: 2012-05-04 16:30 Message: I think the problem is that TimeZoneInof only works with Naive datetime. That is, if you pass in a datetime in UTC, the utcoffset() returns as if it were localtime. EG: from win32timezone import TimeZoneInfo from datetime import datetime import calendar import time tzi = TimeZoneInfo('Pacific Standard Time') tzutc = TimeZoneInfo('Coordinated Universal Time') tz_time = datetime(2011, 11, 6, 4, 0, 0, tzinfo=tzutc) tzi.utcoffset(tz_time).total_seconds()/60/60 shows -8:00 when it should be -7:00 because the datetime is UTC, not localtime. We have a way around this rght now by doing a 2-pass calculation tto see if we crossed the pst/dst time. win32timezone needs a method of showing the utcoffset for a utc timestamp in the specified timezone ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-05-03 05:27 Message: I've started looking into this, and I've expanded the tests you provided: http://a.libpa.st/mP7l7 According to the docs, astimezone should be converting from a very strange form (the time in UTC with the pacific time zone indicated), and fromutc should handle that correctly as long as the standard offset isn't changing on an hour-by-hour basis (which it is not for either of these time zones). http://docs.python.org/library/datetime.html#datetime.datetime.astimezone http://docs.python.org/library/datetime.html#datetime.tzinfo.fromutc I'll continue to investigate, but this is beginning to look like a bug in the datetime implementation (or at least the docs). ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-05-02 13:11 Message: This was using the patched code from #3521185 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-02 20:11:32
|
Bugs item #3523104, was opened at 2012-05-02 13:01 Message generated for change (Comment added) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: TimeZoneInfo does not convert timezones correctly Initial Comment: in the following example two dates are converted from Hawaii time zone to Pacific time zone. In both cases the time difference should be 3 hours. The first is correct, the second is incorrect >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> tzi = TimeZoneInfo('Hawaiian Standard Time') >>> tzs = TimeZoneInfo('Pacific Standard Time') >>> dthaw = datetime(2011, 11, 5, 15, 59, 59, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=15, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=18, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=1) >>> >>> dthaw = datetime(2011, 11, 5, 16, 0, 0, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=16, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=17, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=1) >>> ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-05-02 13:11 Message: This was using the patched code from #3521185 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-05-02 20:01:07
|
Bugs item #3523104, was opened at 2012-05-02 13:01 Message generated for change (Tracker Item Submitted) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: TimeZoneInfo does not convert timezones correctly Initial Comment: in the following example two dates are converted from Hawaii time zone to Pacific time zone. In both cases the time difference should be 3 hours. The first is correct, the second is incorrect >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> tzi = TimeZoneInfo('Hawaiian Standard Time') >>> tzs = TimeZoneInfo('Pacific Standard Time') >>> dthaw = datetime(2011, 11, 5, 15, 59, 59, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=15, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=18, tm_min=59, tm_sec=59, tm_wday=5, tm_yday=309, tm_isdst=1) >>> >>> dthaw = datetime(2011, 11, 5, 16, 0, 0, 0, tzinfo=tzi) >>> print dthaw.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=16, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=0) >>> dtpac = dthaw.astimezone(tzs) >>> print dtpac.timetuple() time.struct_time(tm_year=2011, tm_mon=11, tm_mday=5, tm_hour=17, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=309, tm_isdst=1) >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3523104&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-04-28 01:13:40
|
Bugs item #3521993, was opened at 2012-04-27 05:52 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521993&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dave Blob (daveblob) Assigned to: Nobody/Anonymous (nobody) Summary: pythoncom returns wrong object type Initial Comment: I’m trying to instantiate a 3rd party com object (Bloomberg’s blpapicom2.Session.1), which works fine via: win32com.client.Dispatch (‘blpapicom2.Session.1’) Except for the fact that it returns the interface of another class (IProviderSession instead of ISession). Instantiating the COM object in excel is not problematic - it returns an object with the correct interface. I’ve traced through the C++ code of pywincom, and nothing unusual seems to be happening – I get the right CLSID back from PyWinObject_AsIID (I get {CLSID_Session Class}); When GetTypeInfo and GetTypeAttr are called I get the wrong interface (IProviderSession). Aware that there might be a problem with Bloomberg's COM dll, I wrote my own test in C++ which, I think, makes the calls in the same order as win32com.client.Dispatch: #include "stdafx.h" #include <Objbase.h> int _tmain(int argc, _TCHAR* argv[]) { CLSID clsid; CLSID iid = IID_IUnknown; IUnknown *punk = NULL; IDispatch *result = NULL; ITypeInfo *pti = NULL; TYPEATTR *attr; DWORD dwClsContext = CLSCTX_SERVER; CoInitialize(NULL); LPOLESTR clsName = OLESTR("blpapicom2.Session.1"); HRESULT hr = CLSIDFromString(clsName, &clsid); SCODE sc = CoCreateInstance(clsid, punk, dwClsContext, iid, (void **)&result); SCODE sc2 = ((IDispatch *)result)->GetTypeInfo(0, LOCALE_USER_DEFAULT, &pti); pti->GetTypeAttr(&attr); return 0; } Run from the debugger, attr contains IID_ISession at the end of the program. Inside my Python script PyITypeInfo::GetTypeAttr attr contains IProviderSession. Fearful that something could be happening between python calls, I modified pythoncom_CoCreateInstance to contain: /* BLOB */ ITypeInfo *pti = NULL; SCODE sc2 = ((IDispatch *)result)->GetTypeInfo(0, LOCALE_USER_DEFAULT, &pti); TYPEATTR *attr; pti->GetTypeAttr(&attr); before the final return and attr still incorrectly contains IID_IProviderSession. I've tried this with my current version of Python (2.6.4), a newer one (2.6.8) as well the current release (2.7.3); All are 32bit versions. I'm using Windows 7 64bit. I think all versions as well as my test case were compiled with the 6.0A version of the windows SDK (though I do have 7.0 installed as well). I have an old windows XP machine and it exhibits the same problem (it is running Python 2.6.2), so I don’t think this is a 32/64 bit problem. Instantiating by GUID has the same problem. As an aside, I downloaded OLEViewer and that the Session class is implemented as dual - could this be affecting things? Even so, I'm still confused as to why Excel and my sample code work and pythoncom does not... ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2012-04-27 18:13 Message: One issue I see in your c++ code is that you CoCreateInstance with IID_IUnknown, then just cast the result to IDispatch. You should probably either pass IID_IDispatch to CoCreateInstance or explicitly QI for IDispatch after getting the IUnknown. It might be worth experimenting with both of them to see if that changes the behaviour of the object. Also, another thing you could experiment with is using "makepy" support - ie, use win32com.client.gencache.EnsureDispatch() - this should end up with a makepy generated file where all the interfaces are listed. You should then be able to use win32com.client.CastTo() to get any alternative IDispatch based interfaces from the object. I doubt the fact the interface is "dual" could be the problem but I can see how the wrong IID to CoCreateInstance could cause that (ie, as an implementation detail, they might always provide an IProviderSession, but when there is a QI for IDispatch they provide the other. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521993&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-04-27 12:52:11
|
Bugs item #3521993, was opened at 2012-04-27 05:52 Message generated for change (Tracker Item Submitted) made by daveblob You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521993&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dave Blob (daveblob) Assigned to: Nobody/Anonymous (nobody) Summary: pythoncom returns wrong object type Initial Comment: I’m trying to instantiate a 3rd party com object (Bloomberg’s blpapicom2.Session.1), which works fine via: win32com.client.Dispatch (‘blpapicom2.Session.1’) Except for the fact that it returns the interface of another class (IProviderSession instead of ISession). Instantiating the COM object in excel is not problematic - it returns an object with the correct interface. I’ve traced through the C++ code of pywincom, and nothing unusual seems to be happening – I get the right CLSID back from PyWinObject_AsIID (I get {CLSID_Session Class}); When GetTypeInfo and GetTypeAttr are called I get the wrong interface (IProviderSession). Aware that there might be a problem with Bloomberg's COM dll, I wrote my own test in C++ which, I think, makes the calls in the same order as win32com.client.Dispatch: #include "stdafx.h" #include <Objbase.h> int _tmain(int argc, _TCHAR* argv[]) { CLSID clsid; CLSID iid = IID_IUnknown; IUnknown *punk = NULL; IDispatch *result = NULL; ITypeInfo *pti = NULL; TYPEATTR *attr; DWORD dwClsContext = CLSCTX_SERVER; CoInitialize(NULL); LPOLESTR clsName = OLESTR("blpapicom2.Session.1"); HRESULT hr = CLSIDFromString(clsName, &clsid); SCODE sc = CoCreateInstance(clsid, punk, dwClsContext, iid, (void **)&result); SCODE sc2 = ((IDispatch *)result)->GetTypeInfo(0, LOCALE_USER_DEFAULT, &pti); pti->GetTypeAttr(&attr); return 0; } Run from the debugger, attr contains IID_ISession at the end of the program. Inside my Python script PyITypeInfo::GetTypeAttr attr contains IProviderSession. Fearful that something could be happening between python calls, I modified pythoncom_CoCreateInstance to contain: /* BLOB */ ITypeInfo *pti = NULL; SCODE sc2 = ((IDispatch *)result)->GetTypeInfo(0, LOCALE_USER_DEFAULT, &pti); TYPEATTR *attr; pti->GetTypeAttr(&attr); before the final return and attr still incorrectly contains IID_IProviderSession. I've tried this with my current version of Python (2.6.4), a newer one (2.6.8) as well the current release (2.7.3); All are 32bit versions. I'm using Windows 7 64bit. I think all versions as well as my test case were compiled with the 6.0A version of the windows SDK (though I do have 7.0 installed as well). I have an old windows XP machine and it exhibits the same problem (it is running Python 2.6.2), so I don’t think this is a 32/64 bit problem. Instantiating by GUID has the same problem. As an aside, I downloaded OLEViewer and that the Session class is implemented as dual - could this be affecting things? Even so, I'm still confused as to why Excel and my sample code work and pythoncom does not... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521993&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-04-26 14:36:37
|
Bugs item #3521185, was opened at 2012-04-24 16:54 Message generated for change (Comment added) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521185&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: win32timezone errors in dst/pst Initial Comment: getWinInfo in timeZoneInfo class is return incorrect dynamic info return self.dynamicInfo.get(targetYear, self.dynamicInfo[RangeItemLast()]) self.dynamicInfo is a dictionary, not a List it should be something like: keys = self.dynamicInfo.keys().sort() return self.dynamicInfo.get(targetYear, self.dynamicInfo[keys[RangeItemLast()]]) ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-04-26 07:36 Message: thanks for the quick response... ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-04-25 18:29 Message: Fixed in aa3a7ed32634. It should be safe to copy win32timezone.py into an existing installation as a hotfix. ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-04-25 07:52 Message: The reason this occurs is getWinInfo returns the dynamic entry for 2006, and it should return the entry for 2007 ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-04-25 07:52 Message: Thanks for the update. I'll get it resolved promptly. ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-04-25 07:50 Message: Ok, my apologies I did not look deep enough. The problem is the utcoffset for years 2008-2012 are wrong. 2007 is OK For 2012 it thinks the dst switch is April-1, but it should be March 11 >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> tzi = TimeZoneInfo('Pacific Standard Time') >>> dt = datetime(2012,4,1) >>> print tzi.utcoffset(dt) -1 day, 16:00:00 >>> dt = datetime(2012,4,1,4) >>> print tzi.utcoffset(dt) -1 day, 17:00:00 ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-04-24 20:57 Message: self.dynamicInfo is a dictionary, but it is also a RangeMap. A RangeMap accepts RangeItemLast() as a parameter to .__getitem__ to retrieve the last item (see the docstring for RangeMap). Therefore, it should not be necessary to sort any keys manually. Additionally, the suggestion to use keys = self.dynamicInfo.keys().sort() and keys[RangeItemLast()] would not work because .sort() does not return a value and because RangeItemLast() is not an integer, but a special value indicating the last item in a RangeMap. I'm going to mark this ticket as invalid, because it does not provide any actionable symptoms. Can you provide an example of what you are calling, what you expect, and what happens instead? For me, all of the relevant tests still pass, but that doesn't mean that you haven't found a use case that doesn't work. Please describe it and I'll be more than happy to find a fix. Regards, Jason ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521185&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-04-26 01:29:12
|
Bugs item #3521185, was opened at 2012-04-24 16:54 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521185&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: win32timezone errors in dst/pst Initial Comment: getWinInfo in timeZoneInfo class is return incorrect dynamic info return self.dynamicInfo.get(targetYear, self.dynamicInfo[RangeItemLast()]) self.dynamicInfo is a dictionary, not a List it should be something like: keys = self.dynamicInfo.keys().sort() return self.dynamicInfo.get(targetYear, self.dynamicInfo[keys[RangeItemLast()]]) ---------------------------------------------------------------------- >Comment By: Jason R. Coombs (jaraco) Date: 2012-04-25 18:29 Message: Fixed in aa3a7ed32634. It should be safe to copy win32timezone.py into an existing installation as a hotfix. ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-04-25 07:52 Message: The reason this occurs is getWinInfo returns the dynamic entry for 2006, and it should return the entry for 2007 ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-04-25 07:52 Message: Thanks for the update. I'll get it resolved promptly. ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-04-25 07:50 Message: Ok, my apologies I did not look deep enough. The problem is the utcoffset for years 2008-2012 are wrong. 2007 is OK For 2012 it thinks the dst switch is April-1, but it should be March 11 >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> tzi = TimeZoneInfo('Pacific Standard Time') >>> dt = datetime(2012,4,1) >>> print tzi.utcoffset(dt) -1 day, 16:00:00 >>> dt = datetime(2012,4,1,4) >>> print tzi.utcoffset(dt) -1 day, 17:00:00 ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-04-24 20:57 Message: self.dynamicInfo is a dictionary, but it is also a RangeMap. A RangeMap accepts RangeItemLast() as a parameter to .__getitem__ to retrieve the last item (see the docstring for RangeMap). Therefore, it should not be necessary to sort any keys manually. Additionally, the suggestion to use keys = self.dynamicInfo.keys().sort() and keys[RangeItemLast()] would not work because .sort() does not return a value and because RangeItemLast() is not an integer, but a special value indicating the last item in a RangeMap. I'm going to mark this ticket as invalid, because it does not provide any actionable symptoms. Can you provide an example of what you are calling, what you expect, and what happens instead? For me, all of the relevant tests still pass, but that doesn't mean that you haven't found a use case that doesn't work. Please describe it and I'll be more than happy to find a fix. Regards, Jason ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521185&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-04-25 14:52:45
|
Bugs item #3521185, was opened at 2012-04-24 16:54 Message generated for change (Comment added) made by bmatthews27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521185&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32timezone Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Brian Matthews (bmatthews27) Assigned to: Jason R. Coombs (jaraco) Summary: win32timezone errors in dst/pst Initial Comment: getWinInfo in timeZoneInfo class is return incorrect dynamic info return self.dynamicInfo.get(targetYear, self.dynamicInfo[RangeItemLast()]) self.dynamicInfo is a dictionary, not a List it should be something like: keys = self.dynamicInfo.keys().sort() return self.dynamicInfo.get(targetYear, self.dynamicInfo[keys[RangeItemLast()]]) ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-04-25 07:52 Message: The reason this occurs is getWinInfo returns the dynamic entry for 2006, and it should return the entry for 2007 ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-04-25 07:52 Message: Thanks for the update. I'll get it resolved promptly. ---------------------------------------------------------------------- Comment By: Brian Matthews (bmatthews27) Date: 2012-04-25 07:50 Message: Ok, my apologies I did not look deep enough. The problem is the utcoffset for years 2008-2012 are wrong. 2007 is OK For 2012 it thinks the dst switch is April-1, but it should be March 11 >>> from win32timezone import TimeZoneInfo >>> from datetime import datetime >>> tzi = TimeZoneInfo('Pacific Standard Time') >>> dt = datetime(2012,4,1) >>> print tzi.utcoffset(dt) -1 day, 16:00:00 >>> dt = datetime(2012,4,1,4) >>> print tzi.utcoffset(dt) -1 day, 17:00:00 ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2012-04-24 20:57 Message: self.dynamicInfo is a dictionary, but it is also a RangeMap. A RangeMap accepts RangeItemLast() as a parameter to .__getitem__ to retrieve the last item (see the docstring for RangeMap). Therefore, it should not be necessary to sort any keys manually. Additionally, the suggestion to use keys = self.dynamicInfo.keys().sort() and keys[RangeItemLast()] would not work because .sort() does not return a value and because RangeItemLast() is not an integer, but a special value indicating the last item in a RangeMap. I'm going to mark this ticket as invalid, because it does not provide any actionable symptoms. Can you provide an example of what you are calling, what you expect, and what happens instead? For me, all of the relevant tests still pass, but that doesn't mean that you haven't found a use case that doesn't work. Please describe it and I'll be more than happy to find a fix. Regards, Jason ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3521185&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
