1 Reply Latest reply on Jan 23, 2012 9:31 AM by davisath

    Sending Date from Flex to Java DST Problem

    EliezerReis Level 1



      I don't know what happing but when I check a date before send it to java it`s correct, but when it arrives on my server it comes with one hour left. It start to happen because here, start the DST.


      I observe that in flex now Date GMT-0200 instead of GMT-0300. I observe that Java I have the following print of my ZoneInfo.




      I suspect that BlazeDS, when he's making the parse, isn't looking for the dstSavings attribute but only for the timezoneoffset.


      Is there any solution for this?



        • 1. Re: Sending Date from Flex to Java DST Problem

          For anyone who passes by through this forum. The issue is that Java observes the historic DST intervals and Flex does not. The Flex Date class apparently only accounts for the latest DST interval (March - November) but this has not always been the case. So there will be a window of dates that will be incorrect between the Flex implementation of DST and the Java implementation of DST. As an example, for the year 1964, Flex applies the latest DST interval to that year, the second Sunday of March, but Java applies the historically correct shift to DST which was April 26th. This means that Java will interpret any date up to the 26th of April as standard time. So between the second Sunday of March until the last Sunday of April for any year before the 2007 change in DST, the times will be unsychronized by one hour between Flex and Java. Why does this occur? In the Flex DST/Java DST window described earlier, Flex only accounts for a UTC offset of (X hours from UTC0 - DST hour) where Java accounts for a UTC offset of (X hours from UTC0 + DST hour). If in Eastern time, Flex will apply -GMT0400 and Java will apply -GMT0500, therefore an hour will be lost. Interestingly enough, if the date is inserted into a database and retrieved later, that hour will be added back to the Flex date, so this discrepancy only really applies to logic dependent on a true date from Flex in Java. Since the server has no way of ascertaining what the intended date actually was before the UTC offset was sent this is a particularly annoying issue. It's costly, but I'm entertaining the possibility of having a separate service that does nothing but synchronize dates between Flex and Java. but realistically, I think it's best to avoid Flex for implementing an application that will work with historical dates preceeding 2007 and since Flex is withering in popularity, (probably due to issues such as this) it would probably be advisable to simply avoid it altogether for applications that are integrated into a time sensitive system.