Ok, here's an interesting one. Maybe someone else already went into that one. IAC, here's some explanations. I would also be interested in hearing some comments if others faced that situation as well.

As mentioned in some other threads, some users experienced some weird results when accessing one of our Web Service methods. On that particular method, a date is passed as a parameter. So, it goes like this:

loUniversalThread.GetMessage(DATE())

then, on the server side, the method is defined as this:

FUNCTION GetMessage(tdDate as Date) as String
...
ENDFUNC

So, all is fine here. A date is passed and the method is expected a date.

However, the problem resides for users having a time zone set to something else than the time zone of the server. So, assuming it is 12h45 our server time and the user is having 2h45 local time with the same day, when the date value is received at the server end, it is converted to the date passed minus 1.

When having discussed that with Microsoft, it appears that this is by design. This is the expected behavior.

One aspect of it relates to the fact that the VFP COM type lib is passing a datetime to the WSDL file instead of a date, even if a date is specified at the method level. So, the WSDL is having a datetime for the expected parameter. If you change manually the WSDL file, after the generation, to have a date instead of the date time, it'll work. So, automation should be put in place to resolve that issue, if this applies to you, if you wish to have a success on it.

However, an interesting observation is that if the client uses a .Net Web Service or a VBA for example to call our method, it'll work. We only experienced the behavior from a client using VFP.

But, as Microsoft says, this is by design and this is one way to resolve that issue.