Issue with PHP getting an incorrect date from a C# web service

Question

Ok this has been driving me nuts now for about 12 hours. I have a C# web service running under IIS 7 and I am connecting to it via PHP on a Apache 2.2 box. Not that any of that should really matter but figured I would drop it in.

Now when I go directly to the web service and invoke it I get the correct datetime format but if I call it from php I do not.

Example:

C# WebService: 6/4/2009 9:23:25 AM

PHP Soap Result: 12/31/1600 4:00:00 PM

---

The WebService is assessing WMI::Win32_LogonSession to get the StartTime and then being converted via ManagementDateTimeConverter.ToDateTime((string)wmisearcherData["StartTime"]) and then set to a string.

Im at a lose anything anyone has to offer would be a great help.

Thanks

Answer 1

Try this:

ManagementDateTimeConverter.ToDateTime((string)wmisearcherData["StartTime"]).ToString("yyyy/MM/dd HH:mm:ss")

PHP should interpret that correctly.

Answer 2

I don't think it's getting an incorrect time. PHP is getting "no time at all", and the time value you see is a default value. The beginning of the epoch, as they say. Regardless what value you send, it will always be the same time. This will happen if the format of the XML sent on the wire does not comply with the PHP client's expectations. Actually this is true with any pair of interoperating platforms, not just C# and PHP.

When you use a web service proxy library, the code implicitly maps in and out variables to incoming and outgoing XML documents (or more accurately, XML fragments). Sometimes apps do XML Serialization explicitly, but web services stacks do it implicitly.

There are a variety of reasons why XML de-serialization would fail on the client side. In my experience, the most common cause is a simple XML namespace mismatch. The difference of a single slash on a namespace between the client and server means the XML is not the same. Once I helped a client who fought for days with an XML de-serialization problem like this. Turns out one namespace on his server was missing a slash - someone had innocently trimmed it off for aesthetic reasons.

Aside from XML element name and namespace discrepancies, Date and time formats are a known source of interop problems in web services. That's because there are so many ways to format a time. Is 2006-Jun-14 the same as 2006/06/14? Does 4/7/2007 mean the 4th of July or the 7th of April? Beyond just the formatting issues, you have to concern yourself with the relative meaning of the time value. Is it UTC? Localtime? If it is local, how do you indicate the timezone value?

If anyone else has this problem, here's something you can do to help sort it:
set a debugging http proxy up between the service and the client. Like Fiddler2, or Charles, or Burp or proxyTrace. That way you can inspect the XML on the wire, which will help you figure out why the PHP app is not getting the result you desire.

Often when I have these interop glitches, I will set up a mock service using a homogeneous client and server. In your case this would be a PHP client talking to a PHP server. Using the debugging proxy, look at the traffic generated by the PHP server, which is accepted correctly by the PHP client. You will have to duplicate that in any other service. You can then use the proxy to verify that the content delivered by your actual services complies with what PHP is expecting.