views:

336

answers:

3

I'm receiving a date from a server in milliseconds since 1-1-1970. I then use the DateFormatter to print the date to the screen. However, Flex adds timedifference and thus it displays a different time than what I got from the server. I've fixed this by changing the date before printing to screen. But I think that's a bad solution because the date object doesn't hold the correct date.

Does anyone know how to use the dateFormatter to print the date, ignoring the timezone?

this is how I did it:

function getDateString(value:Date):String
{
    var millisecondsPerMinute:int = 1000*60;
    var newDate:Date = new Date(value.time - (millisecondsPerMinute*value.timezoneOffset));

    var dateFormatter:DateFormatter = new DateFormatter();
    dateFormatter.formatString = "EEEE DD-MM-YYYY LL:MM AA";

    return dateFormatter.format(newDate);
}
+2  A: 

Maybe there is something I'm missing but this seems to work for me.

<?xml version="1.0"?>
<!-- formatters\FormatterDateField.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"&gt;

<!-- Declare a DateFormatter and define formatting parameters.-->
<mx:DateFormatter id="dateFormatter" 
    formatString="EEEE DD-MM-YYYY LL:NN:SS AA"/>

<mx:Label text="Millis (1220836618601 == Monday 08-09-2008 01:16:58 AM):"/>
<mx:TextInput id="dob" text="1220836618601"/>

<mx:Label text="Formatted date UTC: "/>
<mx:TextInput id="formattedDate" 
    text="" 
    editable="false"/>
<mx:Label text="Formatted date local: "/>
<mx:TextInput id="formattedDateLoc" 
    text="" 
    editable="false"/>

<!-- Format and update the date.-->
<mx:Button label="Format Input" 
    click="
        var d :Date = new Date(parseInt(dob.text));
        formattedDate.text=dateFormatter.format(d.toUTCString());
        formattedDateLoc.text=dateFormatter.format(d);
    "/>
</mx:Application>

Suggesting that instead of passing the date object (which is timezone dependant) into the dateFormatter, pass in the date object's UTC String instead. I didn't find anything that would suggest that the DateFormatter does anything to the timezone, so there shouldn't be any need to try to compensate for the timezone, especially when the date object already provides a method for getting the UTC.

function getDateString(value:Date):String
{
    var dateFormatter:DateFormatter = new DateFormatter();
    dateFormatter.formatString = "EEEE DD-MM-YYYY LL:MM AA";

    return dateFormatter.format(value.toUTCString());
}
Matti
A: 

The most simple of fixes is to have as many objects as you can (and properties of objects) be strings. The timezoneOffset solution works fine, but the timezoneOffset for many US cities changes twice during the year. The best rule -- everything is a string.

jeremym
The whole of Europe changes timezone twice a year as well. I don't see how that's a problem. Preferably you would want your program to be aware of that instead of insisting to use the wrong timezone. I agree that the offsetting the timezone by hand isn't the best solution, but neither is disregarding the information. Since there is date functionality in the system, learn how to use it!!
Matti
Hey Matti. I will show you why project architects typically opt for solely using strings when working with AMF data (the first sentance of the question): If you send a date object (AMF serialized) from New York server to a swf in Chicago (regardless of server language), the 12/16/2009 00:00:00 DateObject in New York "toLocalString() traces" as 12/15/2009 23:00:00 PM for the user in Chicago. It is the nature of AMF... and this is why all of the major data intensive projects that are well architected currently use strings for AMF serialized data.
jeremym
A: 

thanks, this method >>value.toUTCString();>> of a value save my day :)

Visit my blog: http://blog.ddsmedia.net

Angel Gabriel Ramirez Alva