It looks that way. Both should be local time values but it appears that wx.GetLocalTimeMillis is returning UTC. Note that this could very easily be a platform specific bug (and I see that Gadget/Steve has confirmed that) as the implementation of that function uses platform specific APIs in some cases rather than C standard library functions like wx.GetLocalTime does. Please create a bug ticket about this at trac.wxwidgets.org. It looks like the same problem exists in 2.9 as well. Here are the implementations of those functions if anybody is curious (or interested in creating a patch to fix the problem <wink>):
Sorry - I should have mentioned in my post that we are on UTC as local
time here in Somerset, (since the end of British Summer Time - our
equivalent of DST yesterday at 0200).
Gadget/Steve
···
On 30/10/2011 8:51 PM, Robin Dunn wrote:
On 10/30/11 7:41 AM, DevPlayer wrote:
On
Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit
(Intel)] on win32 (WinXpSp3)
wxPython '2.8.11.0 (msw-unicode)'
It looks that way. Both should be local time values but it appears
that wx.GetLocalTimeMillis is returning UTC. Note that this could
very easily be a platform specific bug (and I see that Gadget/Steve
has confirmed that) as the implementation of that function uses
platform specific APIs in some cases rather than C standard library
functions like wx.GetLocalTime does. Please create a bug ticket about
this at trac.wxwidgets.org. It looks like the same problem exists in
2.9 as well. Here are the implementations of those functions if
anybody is curious (or interested in creating a patch to fix the
problem <wink>):
I'll take a look at the implementation; although I only have the one
platform and if it's in C++ I'll not likely be able to do much. But
the url to the implimentation is much appreciated; so I can start
learning that stuff.
Which mailing list is most appropropiate for this topic going forward; trac.wxwidgets.org, google wxpython-users, google wxpython-dev?
Anyone on Linux or Max or whatever OS is welcome to show there results too.
Btw I ran this in one slice in Pyslices; because as an interactive
shell it'll run those lines very close together (in time); note to
others testing this.
Oops, I knew you are in the UK so I should have thought about that.
Ok, I've just confirmed that the same problem also happens on Windows for me.
···
On 10/31/11 1:19 AM, Gadget/Steve wrote:
Sorry - I should have mentioned in my post that we are on UTC as local
time here in Somerset, (since the end of British Summer Time - our
equivalent of DST yesterday at 0200).
I've reviewed the cpp code and noted that the error was on the return
statement where timezone was not accounted for. However in the cpp
file, I don't know how to first retrieve the local timezone (in cpp)
and then adjust the values.
<edit>
IE crash., this went to Drafts and didn't post.
<next day>
Well I've been playing around with getting my C++ and 2010 Express C++
compiler working and did some crude C++ snippets with time.h and all
those functions in that library. in that I noticed that in I imported
time and did time.time() in Python and for the first time noticed that
the number returned had digits after the decimal point.
also I was able to create a C++ function that returned the difference
in time between UTC verse Localtime in milliseconds; not the time
stamp but the timezone timespan differeance converted to seconds *
1000.
I figured by adding the return value from that function into the
stoptimer.cpp where the UTC milliseconds was returned in
wxGetLocalTimeMillis function would do the trick. But to be honest I'm
not sure what line of cpp code that is in stopwatch.cpp
···
On Mon, Oct 31, 2011 at 3:09 PM, Robin Dunn <robin@alldunn.com> wrote:
If it needs to go beyond the trac ticket then use wx-dev.
Robin Dunn