Off by one day...and worth writing about...
It's been quite a while since I blogged about anything. I have been very busy but I really should make more time to blog. Some of the bugs I encounter, fix, and yes sometimes re-fix seem familiar. It sure would be nice to read about them to provide myself or someone else a clue now and again.
We have been working on an application which is built using web services. The Java Swing client utilizes JAX-WS and the server was built with Apache Axis. One of the issues we have run into on more than one occasion involves dates. There's a Java class that's used to send date(times) over the wire in XML format which includes the time zone. It's called XMLGregorianCalendar If you're sending or receiving date/times over the wire using Java and web services, chances are you have bumped into it.
One issue we have had to deal with is null date/times. Certainly they can exist in databases and that's not a bad thing. Getting them over the wire may or may not be so easy. We have tested our web services with other languages and null dates can be problematic in other languages as well. We have chosen to address this particular issue with a value representing null. Unfortunately this means we have to test for this value on the client and server but it works.
The other issue that has come up on more than one occasion is easy to solve but very important. The XMLGregorianCalendar includes time zone information. If the time zone is incorrect or unset on the client or server, the date/time will be wrong after it's transferred. We have added code to our client and servers to make sure a time zone is set as we have bumped into several machines where this was not the case.
Recently we noticed something strange on one of two servers on which we are running our application. Every date we entered from the client came back one day earlier after it was saved to the database. As this problem was only exhibited on one of the servers and we had already checked the time zone on the client and both servers, we started looking elsewhere. One server is running Fedora Core 6 and the other is running Fedora 7. Both servers were running Java 6 but slightly different versions. MySQL server and JDBC driver versions were exactly the same. "Off by one day" actually turns up some interesting results if one googles it. Possibilities included all of the above software but the web services on the client and server keep us relatively insulated from any of the possibilities found (not that JAX-WS and Axis have been completely bug free during the time in which I have used them).
Entering the "date" command on the "bad" server returned the current date and time including the "EDT" which indicates "eastern daylight time" and had me thinking all was well. Not until I carefully examined the /etc/sysconfig/clock file did I find the culprit. Instead of ZONE="America/New_York", the file contained ZONE="America/New York".
That missing underscore proved to be the problem. I don't recall having to manually set the time zone on this server but I can't say it was not done by me or someone else. I have found only very limited references to this missing underscore so I don't know if it was a configuration error or a bug in a Linux utility but it's certainly something worth writing about as it may save someone else some time, no pun intended.