Handling Dates across different geographies

This is a tricky one – evaded me for a while. Synopsis of the issue:

Flex messaging (BlazeDS is what we were using) deals with dates in a very special way. The dates are transferred to/from client / server post conversion to UTC and then they get converted to what local time zone. Let me take an example: If you are running the application server (JBoss/tomcat is what we were using) in EDT timezone. Then if a client browser is running in IST time zone the dates would get converted when passed to the server from the client. If a user was to select a date July 29th say 9:00 AM IST, when this date is sent across to the server this will first converted to UTC on the client, then sent to the server across the wire. The server would then convert the time from UTC to EDT time zone. This would mean that time of 9:00 AM IST would get converted to 11:30 PM EDT (pardon me if my time conversions are a little off ~ I hope you get the point).

And this is very much documented by Adobe as “the way” of handling dates and you can not change it without changing the open source code – which i would not recommend.

So, how to solve the issue? There are some quick wins out there, but nothing a realy true fix that i came across. Following are a few links and also my assessment as to why I dont not find them the right fixes:

http://flexblog.faratasystems.com/?p=289

This solution recommends to set the server’s time zone to UTC. Also, they themselves recommend to be careful about global and local time as that can cause some issues. Basically, you can control the time on the server, but you can not control the same on the client which still leaves you with the conversion issues. The time window (as per my example) would be reduced to 5.30 hours, but that will still remain.

http://blog.shrefler.net/?p=13

Again a way to write a helper method that will convert the time on the client (Flex) from local to the UTC which would then be sent over to the server – this solution as proposed askes us to ignore the time zone completely and also needs a helper method that needs to be invoked everywhere you need to send the date back and forth. Works, but not ideal!!

What do I recommend finally?

Well, i tried overriding the serialization mechanism completely – The solution works 🙂 but I have no one to provide me feedback, hence I am looking for suggestions / recommendations here as well.

My need was simple – i did not want to use the time part of the date as the user had selected and hence ignored it completely. We need to do 2 simple configurations:

1. Action Script – Write an AS object that represent a date. This class should implement the flash.utils.IExternalizable interface. This class would the client representation of the date object. The two methods that should interest you are “encode” and “decode” as these are the ones that encode the date into a string and then later on decode the same back to flex object. The file in PDF form

2. Java POJO – A POJO is needed on the server to which the client (AS class) will bind to. Similar to AS, the POJO should be able to decode and encode what is being received and sent. The functions on the Java side are: parseFlexEncoding and toFlexEncoding. Also, similar to AS this class should impement the java.io.Externalizable interface. The file in PDF form

Just put these two classes in place and then use these instead of the OOTB date object and you are all set.

The solution works as I have POC ready for this both in tomcat and JBoss, but I am looking for  feedback and improvements on the same.

Have fun..!

3 thoughts on “Handling Dates across different geographies

  1. It is certainly a tricky issue to tackle, test, and even think about for too long. I don’t know the best approach, but what we did is store exactly what we got from the end user. If we didn’t care about the time(only the date), we set the time to midnight.

  2. thanks for this article. I’ve found it’s actually not terrible dealing with this on the server by only using the UTC value. But unfortunately all the Flex client controls that deal with dates are hard-coded to use the non-UTC properties. So, when you sync the data, the date shows up differently for people in different time zones. So either the Flex team has only provided a half-assed implementation of date-related UI controls, or they just don’t understand how people use dates beyond just a single user in a single timezone. so the choices seem to be either to either roll your own date (as you did), or roll your own date UI controls.

    This problem has been looming on my to-do list for a while and I’m finally starting to work on it. My first try is going to be extending Date, override the non-UTC properties to always return the UTC value. I’m expecting it to be painful but hopefully will work. One issue we have is we store these dates locally (it’s an AIR app) and date objects are cast to Date somewhere in the AIR compiled code. I am hoping it will still cast properly with an extended class.

%d bloggers like this: