0 Replies Latest reply on Jan 20, 2012 9:16 AM by davisath

    Flex Date UTC accessor observes DST erratically

    davisath

      I am currently on a project that has a Flex client with a J2EE backend. There is an issue with dates that we are seeing which I believe to be originating from the Date toUTCString function. I executed a simple test to illustrate my point:

       

      var date:Date = DateFormatter.parseDateString("1964-04-10 00:00:00");

      trace(date.toUTCString());

       

      date = DateFormatter.parseDateString("1964-04-27 00:00:00");

      trace(date.toUTCString());

       

      date = DateFormatter.parseDateString("2012-01-19 00:00:00"));

      trace(date.toUTCString());

       

      date = DateFormatter.parseDateString("2012-04-19 00:00:00"));

      trace(date.toUTCString());

       

      //output

       

      Fri    Apr 10  04:00:00 1964 UTC

      Mon Apr  27 04:00:00 1964 UTC

      Thu Jan 19  05:00:00 2012 UTC

      Thu Apr 19  04:00:00 2012 UTC

       

      This is incorrect since in 1964 daylight savings time began April 26 1964 02:00 AM which means that the UTC offset should have been GMT-0500 (said date was generated in the Eastern time zone) for the first date of 1946-04-10 00:00:00 resulting in Fri Apr 10 05:00:00 1964 UTC.

       

      Because DST is being accounted for in the 2012 date I can only assume that the Flex Date UTC accessor was intended to be designed to account for DST, but it apparently does not consistently do so. This

      becomes an issue when this date will be passed to another API/Framework containing date classes that do account for DST properly over all years it's been implemented. In our case, the Java Calendar class implemented through a SOAP decoder will subtract 05:00 hours from a standard time that the Flex Date UTC accessor only added 04:00 hours to. This means there will be a defect of a one hour discrepancy and in our case that actually results in a day off since the date was generated by a date picker in the front end and the default time is midnight of that date.

       

      Is there a patch for this? If not, how does the Flex community work with other technologies to stay synchronized between standard and DST dates?

      I also tested the UTC functionality on an April and January date in 1943 and to my surprise I observed that the UTC offset indicated that DST was utilized partially that year, but in reality DST was observed every day that year as part of the war effort otherwise known then as "war time". I think that the toUTCString function was coded to account for the last DST shift in 2007 but doesn't account for the changes in DST intervals throughout history, at least not in the U.S.