Flex Pasta » Time Travel: The Curious Case of Java, BlazeDS, and Flex

Time Travel: The Curious Case of Java, BlazeDS, and Flex

Time travel between Flex, BlazeDS, and Java can be quite complicated to keep the three correctly in sync.  Time travel, aka remote objects that carry date members, can mean different things to each piece of software.  Java is very time zone aware, where as Flex is very time zone unaware.  Since time in Java, BlazeDS, and Flex is defined in milliseconds since 1970, it can mean translation via BlazeDS can result in inconsistencies.  How can this be?

Java

Desmond LostWhen it comes to time zones and daylight savings time, Java is very smart.   It uses the Olson Database to determine how to translate a time in milliseconds since 1970 into an actual date/time based on the current timezone.  The Olson Database knows when daylight savings time started and ended in each time zone each year.  If you remember, prior to 2007, daylight savings time in the United States started the first weekend in April and ended the last weekend in October.  But, it an effort to be more energy conscious, the government changed it to the second weekend of March through the first weekend in November.  Java knows about daylight savings time and time zones as they existed in the past.  Therefore, milliseconds since 1970 for a date of March 15th, 2006 in Java maybe different than on another platform.

BlazeDS

BlazeDS(and the Flex RPC library) translate time via AMF between Flex and Java.  It knows nothing about time zones or daylight savings time.  When sending a remote object that contains a date, it will be converted to date.getTime() - milliseconds since 1970.  BlazeDS is always translating dates in the present and has no understanding of the client and server’s time awareness.

Flex

Flex only knows about daylight savings time now.  Meaning, Flex will think March 15th, 2006 was during daylight savings time.  But in 2006, daylight savings time didn’t start until April so Java will have a different answer than Flex to milliseconds since 1970?  To be fair, it is not Flex or Flash that aren’t time zone savy.  It is the user’s browser and computer that are ultimately at fault.  The flash player will just pull the information from them.  Imagine if a user enters a date/time today(during daylight savings time).  At some point in the future, the government changes daylight savings time to start tomorrow.  After the change occurs, the date the user entered will be correct in Java(because Java knows of daylight savings time in the past), but will be one hour off when displayed in Flex.

Creating an identical date/time object in both Flex and Java can cause different results for milliseconds since 1970.  Take for example a user entering a birth date on a Flex form as March 15th, 2006 and another user entering a birth date as March 15th, 2009. The following screen shots show a simple Flex app with a date chooser and a label showing the time in milliseconds since 1970.

Flex Reports Milliseconds since 1970 for March 15, 2009.Java Reports the date March 15, 2009 after given the milliseconds from Flex.

When the user selects March 15, 2009, the date is correctly translated to Java via BlazeDS as March 15th, 2009.  Notice that Java says EDT(Eastern Daylight Time).

Now look at the same test for March 15, 2006.

Flex Reports Milliseconds since 1970 for March 15, 2006.Java Reports the date March 15, 2006 after given the milliseconds from Flex.

Notice for the March 15th, 2006 date translation is incorrect.  The date given to us via BlazeDS will actually be on March 14th at 11pm.  Java correctly identifies the time zone EST(Eastern Standard Time).  Java is correct.  Back in 2006, March 15th was during eastern standard time.  Because this date today is in eastern daylight time, Flex incorrectly reports milliseconds since 1970 to a number off by one hour.

Now the incorrect birth date is put in the database as March 14th!!   Want to run a query to find all people born on March 15th, 2006?  That could be a problem.  There are several ways to solve this problem.  One might be creating a JustADate class that has year, month, day fields on it so BlazeDS will send it without using getTime().  Another option might be sending date only fields as strings to avoid the getTime() translation.  When working with dates in Flex, BlazeDS, and Java, be sure to consider time travel and its inconsistencies!

“Once confined to fantasy and science fiction, time travel is now simply an engineering problem.”   -Michio Kaku

Monday, June 1st, 2009 BlazeDS, Flex 3, Java Trackback URL for this entry

10 Comments

  • 1. PaulH replies at 1st June 2009, 6:50 am :

    well i’ll be damned. we’ve used epoch offsets between flex & cf to handle apps that need to be in multiple timezones (tz). never noticed that historical dates are off & i’m usually the 1st guy to start in on tz.

    rats.

  • 2. AF replies at 4th June 2009, 8:46 am :

    Hi Brian,

    I’m trying to contact you, but I can’t find a contact us page on the blog. Please contact me at the email provided.

    Thanks,
    AF

  • 3. Ryan replies at 5th June 2009, 1:01 pm :

    I have seen some strange things with dates in Flex. Most notably, I found this post by searching for a way to make DateFormatter at least print the time zone it is rendering the time in relation to - since I have an app that displays times of certain events - and it’s confusing for someone on the east coast to view an event that happened in the west coast and see it in east coast time.

    Turns out, DateFormatter seems blisfully unaware of what time zone it is even in! (like you mentioned)

    What an annoying way of dealing with time.

  • 4. Daniel replies at 10th June 2009, 12:44 am :

    While it handles the time/timezone concept in a very complex way, Java does not handle things in a very smart way. Java is one of the biggest culprits when it comes to the fundamental flaw in the way that modern computer science handles dates - the belief that that a date/time is an absolute time and that the only “pure” way to handle it is to have a “Universal” frame of reference. The example above is a very good one - birthdays as a concept are independent of location. When someone says “when is your birthday” they wouldn’t dream of adjusting the answer because you are currently in New York but at the time of your birth you were in Sydney. Some Date/times are really points in time (what exact time did an event occur) and some conceptually fixed without having a specific timezone attached (when is your 25th wedding anniversary).
    The above example mostly outlines the problems caused by Flex not being able to handle the date in the same complicated timezone dependent way as java, the real issue is that we should have a pure timezone independent date type in both flash/flex and java as the timezone is completely irrelevant to the business situation (i.e. birthday recording) and the insistence that date/times inherently include timezones is fundamentally flawed.
    Pardon me for my rant but it’s an issue that has been annoying me for at least a decade.

  • 5. Kris Hofmans replies at 10th June 2009, 8:54 am :

    I have had lengthy discussions with adobe support on this issue!

    The biggest problem with it is that it’s not consistent from platform to platform.

    If you use mac os x or linux the dates get translated to the same values as they were on the server-side. When you use windows the native windows date/time methods convert it to the wrong date for the corresponding timestamp.

    They have assured me that this will be dealt with in flash player 11 most likely by including their own olsen db and corresponding date/time handling in the player itself rather than relying on the native os.

  • 6. Shih-gian Lee replies at 19th June 2009, 8:30 am :

    Brian, good post!

    One thing that we keep forgetting when working with Flex is Flex is a distributed platform. What this means is it is built for multiple platforms, .Net, JEE, ColdFusion. This is one of the classic distributed problems dated back in CORBA days. In favor of performance over loose coupling, Flex uses AMF binary protocol to covert objects back and forth and this is called onject serialization. Flex’s BlazeDs/LCDS is like EJB 2.x. EJB follows the footstep of CORBA and it died horribly. Flex technology is getting more complex everyday and not fun to program in. I am afraid it will die horribly like EJB or CORBA if it does not anything to simplify its programming model with the help of the open-source community. I would rather program in traditional web with the help of Ajax for its richness than working with Flex. Object serialization posses great problem in modern distributed technology such as Web Services as well. It is not the Web Services problem, it is the people who use Web Services wrong. Granted, Web Services should be blamed for its complexity as well. Instead of sending data back and forth as messages, people choose to send data back and forth in binary form. Hence, your service is not technology agnostic and couple to the specific platform. Brian, your solution to send date as String instead of letting platform handles the serialization is the correct and recommended approach. I “strongly” recommend everyone who encounters this problem to use this approach. This way, the date will be platform independent. There is nothing Adobe can do to solve this problem, as Kris mentioned.

    @Daniel: I have different opinion about the date for birthday. If a store is giving out discount on a customer’s birthday, it should be taken into account of the timezone he or she currently is in. I would not want to reward the customer too early or too late, correct? As you mentioned in your last sentence, you may have the requirement to record birthday independent of business requirement, then you just have to treat the date as String and do whatever you want on your end.

  • 7. Gubber replies at 5th July 2009, 4:31 am :

    Hi, Brian.
    Thanks for your blog it’s wery usefull. I very interesting in Java vs Flex integration.
    Now I have one question.
    Can I access my java services without …
    I want to access to my endpoint from as-class. But I can’t find any samples how set an endpoint to RemoteObject.as object
    If you have some ideas in this may you send me a little bit of your ideas. Or it will be better to see a post in your blog, how can access to java services in another way.

    Alexey.

  • 8. Nick replies at 16th September 2009, 2:30 pm :

    Excellent post! Does anyone have an example of how people are doing the “date as string” thing to get around this issue? Thanks!

  • 9. Martijn replies at 3rd October 2009, 10:51 am :

    I had this problem once in a project using Axis. Same date issue there when using xsd:date types. Due to the Z converting the time to UTC, which, for a Date without time, causes problems for different timezones (yyyy-MM-dd’Z').
    The solution here was to convert date to string without ‘zoned time’. This implies that the receiving side also has to be aware of this workaround.

    When using Flex and Java communication via BlazeDS I decided to create my own datatype mapping. Actually to solve the lack of enumeration types in Flex. This resulted in a Flex/Java/BlazeDS/Spring generator. We just launched the Paddle generator a few weeks ago. Paddle can be used online on . The adventage of generating Java/Flex classes is, besides saving the type work, that data conversion issues can be solved in structured way.

    At the moment we are still working on the generator to create a correct mapping for every possible Java/Flex datatype. Also we are working on this specific date problem.

    There will be always issues when combining different frameworks, but in my opinion Flex and Java make a good couple and complete each other very well. The coolest UI and robusteness and flexibility at the back end.

    -Martijn.

  • 10. Brice replies at 19th January 2010, 7:27 am :

    Hi,
    I use your book on enterprise Flex with BlazeDS but where is the site web to get source code’s examples.
    Brice

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>