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");
date = DateFormatter.parseDateString("1964-04-27 00:00:00");
date = DateFormatter.parseDateString("2012-01-19 00:00:00"));
date = DateFormatter.parseDateString("2012-04-19 00:00:00"));
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.