2 Replies Latest reply on Mar 12, 2009 11:11 AM by Ansury

    Data Services Date conversion error?

    Ansury Level 3
      I've seen this before (I'm guessing last year about up until DST ended) but it kinda "disappeared" as an issue until now. I was able to put the issue off last summer but now I need a fix.

      Sending a Flex Date object over to Java of (for example) March 10 0:00, when converted to a Java object, turns into March 9 23:00.

      ...ugh. It seems Flex is adding an extra hour (as it should be) but Java doesn't care for it and decides to use what I guess is standard EST.

      I've verified in debuggers on both sides that this is happening. My questions now are why, and is there an easy way around it?

      My thoughts are that perhaps it's a Granite Data Services error. I'm not using BlazeDS which may explain why it doesn't seem to be a common topic on teh Intarwebs yet. But given Java's reputation with handling dates I wouldn't be too surprised if it was a Java problem. Anyone seen this issue?
        • 1. Re: Data Services Date conversion error?
          SujitG Level 2

          Please check if the bug mentioned in the URL below is the reason.


          Hope this helps.
          • 2. Re: Data Services Date conversion error?
            Ansury Level 3
            Found the issue. Turns out, it's not that, nor is it a Flex related error whatsoever. Although, I bet that issue has a similar cause.

            This took some detective work.
            It's a Java problem, although it's not an error, just a matter of being outdated. In 2007 the goofy US gov decided to change when EDT started. My JDK (5.0) was downloaded in 2005. See the problem?

            When Flex and Granite DS send a perfectly correct date (literal time, number of ms passed since Jan 1 1970) to Java, Java's Date implementation takes this value and calculates the day, month, time etc based on timezone. Since the timezone data it's using is outdated (not accounting for the 2007 change in the US), it gives wrong results--until after the day that (it thinks) daylight savings is supposed to start.

            It's only one hour off (not a full day), but subtract one hour from March 9, 2009 0:00. You get March 8, 2009 23:00. Oops. Even if you don't care about the time (I don't), the day is still off after going back in time one hour. Der!

            Adding to the mystery, if you do nothing to fix the problem and you tend to use dates close to the current date for your intial/dev testing, the problem vanishes after the 'old' DST start date, and doesn't re-appear until you use a date within that narrow range of days.

            The fix is to get the latest release of whatever Java JDK you're using... simple.