The missing hour

For one of our customers we produce a series of reports on the transactions performed in their shops. We only capture some of the data on the mobile client and the rest of the information is obtained by querying a web service that accesses the customer’s point of sale system.

During customer acceptance testing they reported that we had the times for some of the transactions wrong. The transactions were an hour off, putting them in the wrong day. Daylight saving had ended during the customer acceptance so someone suggested that this may be the cause of the issue. Unfortunately we could not tie this to the cause and times were still being recorded incorrectly a few weeks later.

The web service ran over HTTPS so it was hard to see what was in the message initially - we could see what was received and stored in our database but couldn't see what they were sending us. They eventually sent us a message log from their server. We then were able to confirm that the time string in the message for the transaction time did not match the one we were storing in the database.

It looked like the problem was somewhere in the decoding of the SOAP message. This was in code generated from the WSDL. We just got a Calendar object back from the generated code. I looked up the W3 spec for SOAP encoding (Remember steps 1-3: Understand the system, Understand the problem, gather information). I  noticed that the format used for transmitting times in SOAP messages cannot be easily converted back to a Calender or Date object using the standard java date format converters. From the JDK documentation I saw that there is a special class for converting W3 date/time data types. I built a small test program and ran the date time string from the WS call through the JDK converter class. The program returned the correct value.So why didn’t the generated code work correctly?

We looked through the generated code and and discovered that the generated code used another class to convert the string in the message to a calendar object. We modified the test program to use the other class and it gave the result that had the issue reported. (Now we had a reproducible problem). Looking at the source for the problem class it looked like the class did not handle the timezone component in the date/time string from the WS call. We were in a rush so we just modified the generated code and swapped in the JDK class. Issue Resolved.