JAJAH Development Blog

Blogs by JAJAH Developers

Archive for the ‘DateTime’ Category

Sunday, June 1st, 2008

I’m sure all of us developers has stories where they submitted code, after carefully debugging and testing it, only to get 5 minutes later rejects from QA and you’re clueless for the reason. This is one of those stories.

We’re developing a VoIP client. One of the features is letting the user know if she missed calls while the client was off-line. In order to do this, we ask for the mobile’s time. Problem is, mobile devices has a tendency for not having an accurate time. It might be because mobile users adjusted the time but keep using manufacturer default time zone. It can also happen that you forgot to adjust the time properly while traveling abroad. In some cases, your fancy device might just decide to reset itself for no apparent reason. At any case, chances are that the device’s time is not the same as your server. This is obviously true when dealing with global service provider like JAJAH that supplies services to users around the world.

Back to the the client. We decided to send the local time of the device over a Web-Service and have the back-end server send back missed calls and adjust time of call with the client’s local time. All went nice and dandy on our development environment. Results came back as they should have, edge cases were also tested and worked flawlessly. Then, we gave the client to our QA team.  After a while, they came back telling that there’re inconsistencies with the missed call features. So frustrating!

I won’t bother you will all the details. Eventually, it turned out that DateTime is a wise-guy object. It has a kind property which affects the result of WS de-serialization. The local device-time we sent from the client was de-serialized to UTC time on the server side. So, everything worked fine as long as the device and the development environment were both on the same time zone (GMT +2). Once we moved to an environment in New-York (GMT -8), the server thoughts we’re looking for missed call that are due in 10 hours. Indeed, quite a paradox.

In order to fix the issue, and make sure that the DateTime objects is not converted to a UTC format, simply make sure use the unspecified kind.  For example:

DateTime myDateTime = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);
This post is dedicated to Boaz for his great help in solving this problem.

Jajah is the VoIP player that brought you web-activated telephony.