What is the problem with this? This is not a real date-time, but "tick count"
that starts when the system starts. And it rolls over once in a while too (this
is the way it is on windows).

Microsoft's docs say this: "The system time returned in dwTimeStamp comes from
the same clock used by the Microsoft Win32GetTickCount or timeGetTime functions,
but it produces potentially more precise values. For example, on Microsoft
Windows 95, the GetTickCount timer is updated only every 55 milliseconds, but
the dwTimeStamp value is accurate to within 1 millisecond. Therefore, if you
call GetTickCount and it returns n, and you then receive an event with a
timestamp of n + n1, you cannot assume that the event took place exactly n1
milliseconds after the call to GetTickCount."

Your timestamps differ from GetTickCount by my system uptime.  GetTickCount will
say something like 20000 milliseconds and the joystick timestamp will be
80000000.  You aren't off by 55 milliseconds, you are giving timestamps that are
a day into the future.

Yeah the time stamp Wine uses is exactly what it receives from the system.
However I don't see any problem with that. Unless you have a real life app that
brakes because of this, there is nothing needs to be done here.

I made a workaround for my app, but the bad timestamps will break apps that
depend on them.  Say you have a simulation that can only render at 10hz, but
runs its physics at 100hz.  Every 100ms it will run 10 physics steps.  For the
first step, it will only consider joystick events that happened before
timeGetTime()-90ms, for the next step it will consider events before
timeGetTime()-80ms and so on.  With the timestamps as they are now, an app that
works like that will end up ignoring joystick events because the timestamp says
the event hasn't happened yet.

To get it right wine has to record the GetTickCount() time when the joystick is
opened and the timestamp from the linux joystick's JS_EVENT_INIT and then
subtract the difference between the two from each subsequent joystick event
timestamp.

If that is too much trouble, it would probably be better to ignore the linux
joystick timestamps entirely and just use the current time.  At least it won't
be off by days then.

If you didn't understood this is a not guaranteed behavior. You can not relay on
this to be what you using it as.

In _all_ input functions windows does use time-ticks in one way or the other.
However you CAN NOT relay on their starting point! Also you are missing the fact
that GetTickCount returns 32-bit number that will roll over after approximately
50 days.

Anyway, if this is your own program, you better change it. If it's the program
you bought, you better file a bug with their developers.

I understand perfectly well what the system time is.  I know that it doesn't
start from a fixed date and that it wraps every 49.71 days.  What you don't seem
to understand is that your joystick times are in a different time frame than
Wine's system time.  You can call GetTickCount() and get 20000, then read a
joystick event that says it happened at 80000000, then call GetTickCount() again
and get 21000.  That is clearly wrong.  The timestamp is supposed to be the
"System time at which the input event was generated, in milliseconds", not the
system time plus some random offset.

If you don't believe that is how it's supposed to work, look at Quake 3's source
code.  You will see DirectInput timestamps used exactly as I described. 
(Luckily they only use DirectInput to read the mouse, not the joystick, so they
don't hit the bug.)

Anyway, I am done wasting time on this.  Do what you will.

Vitaliy, don't be silly, that's a real bug. Of course the starting point for
timestamps is arbitrary, but it has to be the same for all timestamps.

Is this still an issue in current (0.9.59 or newer) wine?

Yes.

Ping.

Is this still an issue in current (1.1.20 or newer) wine?

Abandoned. If this is still an issue in current (1.1.32 or newer) wine, and you can provide the needed information, feel free to reopen.

Yeah still an issue. Will take a look at it, even tho OP didn't provided an app affected by it.

Still present.

Replacing ie.time.tv_usec with GetCurrentTime() in dlls/dinput/joystick_linuxinput.c should solve this problem (I only use Wine on Mac OS X, but I went through the Linux code while looking into how to fix bug 18424 ).

And also replace jse.time with GetCurrentTime() in dlls/dinput/joystick_linux.c

Created attachment 41543 [details]
Patch to correct the joystick event timestamps

I know that patches should be sent to the wine-patches list, but I don't use Linux for gaming and hence the attached patch is 100% untested (I didn't even check whether it compiles).

Anyone else is free to test and submit it.

Fixed by http://source.winehq.org/git/wine.git/commitdiff/bfafb1ffc5a102966025b5b9f3acb81fea5435d1

Closing bugs fixed in 1.7.9.

Removing 1.6.x milestone from bugs included in 1.6.2.