|
From: SourceForge.net <no...@so...> - 2007-09-04 14:43:53
|
Bugs item #1784777, was opened at 2007-08-30 06:12 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1784777&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: Bernhard (bernhard_bender) Assigned to: Nobody/Anonymous (nobody) Summary: wrong timezone info returned by GetTimeZoneInformation() Initial Comment: In my setting: Windows XP (German), up-to-date patches applied (including the lated August 2007 timezone database patch) Python 2.4 pywin 2.10 Timezone Europe/Berlin (+0100) with DST enabled win32api.GetTimeZoneInformation() returns seemingly wrong information for the date DST ends. This is shown by the little scripe I have attached, which prints: >>> Daylight time begins : Last Sunday in March Daylight time ends : Last Thursday in October <<< Since I am pretty sure that our DST does not end on a Thursday, I suspect an error in either the implementation of GetTimeZoneInformation() or in the WinXP TZ database. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 08:43 Message: Logged In: YES user_id=599869 Originator: NO Indeed, that's my finding as well. It's probably not appropriate to construct a PyTime from the SYSTEMTIME structure in GetTimeZoneInformation, as it's using the day of the week value explicitly. In the meantime, Bernhard, you may try using the win32timezone module. I wrote it, and it reads from the registry directly to provide richer timezone support than the Microsoft system calls. >>> import win32timezone >>> my_tz = win32timezone.GetLocalTimeZone() >>> my_tz.GetDSTStartTime(2007) datetime.datetime(2007, 3, 11, 2, 0) Note there are some changes to this module that aren't in the current release of pywin32 (build 210). I will attach the latest win32timezone.py to this bug for convenience. ---------------------------------------------------------------------- Comment By: Bernhard (bernhard_bender) Date: 2007-09-04 08:32 Message: Logged In: YES user_id=1637368 Originator: YES I had been doing some digging in the source code. I may well be that the problem stems from the fact that the date for changing time zones is stored as a float (seconds since the epoch). As such it does not explicitly store the day of week, but rather the day of week is recalculated in the Format() method. Thank you for looking into this. Bernhard ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 08:25 Message: Logged In: YES user_id=599869 Originator: NO I looked into the .NET platform, but it uses a completely different mechanism, apparently, so it was little help. ipy >>> from System import TimeZone >>> localZone = TimeZone.CurrentTimeZone >>> print localZone.StandardName Eastern Standard Time >>> localZone.GetDaylightChanges( 2007 ).Start <System.DateTime object at 0x000000000000002D [11-Mar-2007 02:00:00]> BTW, 11-Mar is correct (not 10-Mar like I mentioned earlier). ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 08:13 Message: Logged In: YES user_id=599869 Originator: NO It's not immediately clear to me what's going on here. It does appear as if GetTimeZoneInformation() is returning the wrong values. >>> win32api.GetTimeZoneInformation() (2, (300, u'Eastern Standard Time', <PyTime:01-Nov-2000 02:00:00>, 0, u'Eastern Daylight Time', <PyTime:02-Mar-2000 02:00:00>, -60)) One interesting point to note is the date is 2000 (not 2007). I don't know why this would be. This year, it should be 04-Nov and 10-Mar. The 01-Nov and 02-Mar does coincide with first and second weeks, so perhaps pywin32 is misinterpreting the structure? It's just a SYSTEMTIME, so that seems unlikely. I suspect this problem emerged with the introduction of dynamic time zones. I'd be interested to see what the results of GetDynamicTimeZoneInformation or GetTimeZoneInformationForYear would produce. I think the next steps are to (a) double-check the source to confirm the fields are being parsed correctly and (b) to call this from another platform (native C++ or .NET) to see what the results of the call are. Bernhard, would you be willing to return the output of the raw GetTimeZoneInformation() call? I think that would help me prove or disprove my theory of the fields being mis-interpreted. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 07:40 Message: Logged In: YES user_id=599869 Originator: NO I am seeing this behavior on my US Win Vista machine also. I will investigate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1784777&group_id=78018 |
