[pywin32-bugs] [ pywin32-Bugs-1784777 ] wrong timezone info returned by GetTimeZoneInformation()

[SourceForge.net <no...@so...>]

Bugs item #1784777, was opened at 2007-08-30 08:12
Message generated for change (Settings changed) 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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Bernhard (bernhard_bender)
Assigned to: Jason R. Coombs (jaraco)
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: 2009-07-12 09:27

Message:
This was fixed for build 213 and 214.  Please comment or re-open if this
problem exhibits itself once again.

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2009-01-31 09:03

Message:
I think the solution is to use win32api.GetTimeZoneInformation(True),
available in the forthcoming pywin32-213, to get tuples instead of the
PyTime structures, which then contain the unaltered elements of a
SYSTEMTIME structure.

Alternately, the new release has direct support for parsing the result of
the API call: win32timezone.TimeZoneInfo.local()

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2009-01-31 00:59

Message:
Jason, I think this has been addressed in the most recent win32timezone
changes?  Bernhard, please keep your eye open for build 213 which has this
new version.

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2007-09-04 21:26

Message:
Logged In: YES 
user_id=599869
Originator: NO

I'm attaching a patch that demonstrates (perhaps incorrectly) a way to
address this issue.  I've never done PythonC programming (that is,
extensions to python in C/C++).  I used to know C++ like the back of my
hand, and now it looks Greek to me.

What I think I've proposed will change the return value for
GetTimeZoneInformation, which will break prior implementations that depend
on it.  I think Bernhard has demonstrated, however, that any
implementations that depend on it are probably flawed anyway, so that's why
I'm suggesting changing the interface.

I think the patch returns a tuple of 8 ints (they're defined as WORDs in
the specs) instead of converting to the PyTime object (via
PyWinObject_FromSYSTEMTIME).

This could probably better be implemented with a different class (instead
of PyTime) to represent SYSTEMTIME when converting to variant time is
inadequate such as in this case.

Although this is assigned to me, I'd like to defer to Mark as to how he
would like to approach this issue.  Mark, if you would like me to fully
test and implement a full patch, I'll need some assistance on getting a
PyWin32 development environment set up.
File Added: win32apimodule.cpp.systemtime.patch

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2007-09-04 19:18

Message:
Logged In: YES 
user_id=14198
Originator: NO

Hi jason,
  Thanks for your comments.  I've taken the liberty of adding you to the
pywin32 project and making you an admin in various places, so now you can
be assigned bugs (which I've done here) and should also be able to make any
changes to them.

Cheers

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2007-09-04 10:45

Message:
Logged In: YES 
user_id=599869
Originator: NO

It seems I can't attach files to a bug I did not create.

----------------------------------------------------------------------

Comment By: Jason R. Coombs (jaraco)
Date: 2007-09-04 10: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 10: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 10: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 10: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 09: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