<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Timezone Issues with remote (Date/Time) data and flash</title>
	<atom:link href="http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/</link>
	<description>Axel Jensen on Flex, Coldfusion and... other stuff</description>
	<pubDate>Thu, 07 Aug 2008 22:19:01 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Pat Buchanan</title>
		<link>http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/#comment-349</link>
		<dc:creator>Pat Buchanan</dc:creator>
		<pubDate>Thu, 27 Mar 2008 20:22:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/#comment-349</guid>
		<description>Amen to that.  I've been fighting this thing for 2 days before I finally figured out that it was being automatically converted for me.  In some of my apps, this is great because I'm doing it all manually right now.  In others, I *need* the exact date from the server.  I don't care how their computer is setup timezone wise.  If I say midnight, I mean midnight.

And with everyone saying to use UTC - I don't see the immediate benefit since I'll have to loop through and edit any data I get from the server anyway.

If you find a good, easy solution to this, let me know.  For now, I'm converting everything over to strings (lucky for me I own the server side as well).  Seems like a hack to me.

Thanks</description>
		<content:encoded><![CDATA[<p>Amen to that.  I&#8217;ve been fighting this thing for 2 days before I finally figured out that it was being automatically converted for me.  In some of my apps, this is great because I&#8217;m doing it all manually right now.  In others, I *need* the exact date from the server.  I don&#8217;t care how their computer is setup timezone wise.  If I say midnight, I mean midnight.</p>
<p>And with everyone saying to use UTC - I don&#8217;t see the immediate benefit since I&#8217;ll have to loop through and edit any data I get from the server anyway.</p>
<p>If you find a good, easy solution to this, let me know.  For now, I&#8217;m converting everything over to strings (lucky for me I own the server side as well).  Seems like a hack to me.</p>
<p>Thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joss</title>
		<link>http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/#comment-212</link>
		<dc:creator>Joss</dc:creator>
		<pubDate>Wed, 12 Mar 2008 20:22:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/#comment-212</guid>
		<description>Axel,

Instead of looping through your data, there is a great post from farata systems, that you might want to consider.
http://flexblog.faratasystems.com/?p=289
Hope this helps.

-Joss.</description>
		<content:encoded><![CDATA[<p>Axel,</p>
<p>Instead of looping through your data, there is a great post from farata systems, that you might want to consider.<br />
<a href="http://flexblog.faratasystems.com/?p=289" rel="nofollow">http://flexblog.faratasystems.com/?p=289</a><br />
Hope this helps.</p>
<p>-Joss.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: admin</title>
		<link>http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/#comment-171</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Mon, 10 Mar 2008 17:46:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/#comment-171</guid>
		<description>I couldn't agree with you more on your solutions, I did think about the timezone offset, but the problem is the amount of data we have coming back in the application is too much to touch it and adjust the offset manually... 

unfortunately the date in the db is stored as an sql "smalldatetime" and thats how it comes back, not as UTC, i've been told there are built in ms sql functions to do conversions, but have not tried it out... 

so the problem here is really that we're not storing the dates correctly in the db, but the thing is, almost every application i've worked on just uses date/time in sql... because it's a great solution and covers most issues as far as needing to filter on dates and things like that.  

it is just wierd that flash does that out of the box... i would have thought for it to be the other way around... as in, in order to use the timezone of the local machine it would be a player setting in the html wrapper that you specify... 

anyway... thanks for the comment.</description>
		<content:encoded><![CDATA[<p>I couldn&#8217;t agree with you more on your solutions, I did think about the timezone offset, but the problem is the amount of data we have coming back in the application is too much to touch it and adjust the offset manually&#8230; </p>
<p>unfortunately the date in the db is stored as an sql &#8220;smalldatetime&#8221; and thats how it comes back, not as UTC, i&#8217;ve been told there are built in ms sql functions to do conversions, but have not tried it out&#8230; </p>
<p>so the problem here is really that we&#8217;re not storing the dates correctly in the db, but the thing is, almost every application i&#8217;ve worked on just uses date/time in sql&#8230; because it&#8217;s a great solution and covers most issues as far as needing to filter on dates and things like that.  </p>
<p>it is just wierd that flash does that out of the box&#8230; i would have thought for it to be the other way around&#8230; as in, in order to use the timezone of the local machine it would be a player setting in the html wrapper that you specify&#8230; </p>
<p>anyway&#8230; thanks for the comment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kldavis4</title>
		<link>http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/#comment-139</link>
		<dc:creator>kldavis4</dc:creator>
		<pubDate>Thu, 06 Mar 2008 14:19:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.axelscript.com/2008/02/20/timezone-issues-with-remote-datetime-data-and-flash/#comment-139</guid>
		<description>Axel,

I am not entirely clear on the issue here. First of all, if you are getting a UTC date from your server, then the data will be correct, assuming it is getting treated as such and not manually parsed into a Date object. If it is UTC, then you would expect to see different times for people in different time zones. 

It sounds like what you really want is that the dates being viewed by the client be displayed as if they come from a specific time zone regardless of the client machine's operating system time zone setting. I actually ran into this issue with one of my applications. User's of this application could change their time zone within the application, regardless of what the machine was set to. This works fine on the server side, because we were working with UTC dates and stored a time zone preference which could then be used to display the correct date to the user based on their time zone. When we added our flex app into the mix, it became a problem, though, because if we passed the utc date to the flex app, there was no way to format it based on the user's time zone, but instead the machine time zone setting. So I came up with a couple of solutions to this problem, none of which is particularly elegant, but I can live with it because I believe they are working around a fundamental flaw in the flash player (ie not being able to configure your time zone from within the vm).

The first solution is to transform your date/time value into it's string components, and then parse it into a date object on the client. The server determines the time zone used to get the "display" date (as opposed to utc date), and you send the month, date, year, hour, min, sec, etc fields to the client and it gets re-assembled.

The second solution is to find the time zone offset of the client and adjust values based on that. You do this by having your client send a specific known date to the server in UTC. You create a date using the , say 01-01-2000 00:00:00:0, using the year,month,date,hour,minute,second,millisecond constructor of the Date object, and then send the UTC value of that date object to the server. The server does the same thing, but using the specific time zone that you are 'targetting'. Then you get the utc value of this date, and find the difference between it and what the client sent you. This will give you the time zone offset of the client, which you can send back to the client. Then just roll each date that the server sends to the client by this amount.

This still requires that you touch the data somewhere along the line, either on the server or the client, but there is just no way around it if you want the dates displayed using a time zone other than what the user's machine is set to.</description>
		<content:encoded><![CDATA[<p>Axel,</p>
<p>I am not entirely clear on the issue here. First of all, if you are getting a UTC date from your server, then the data will be correct, assuming it is getting treated as such and not manually parsed into a Date object. If it is UTC, then you would expect to see different times for people in different time zones. </p>
<p>It sounds like what you really want is that the dates being viewed by the client be displayed as if they come from a specific time zone regardless of the client machine&#8217;s operating system time zone setting. I actually ran into this issue with one of my applications. User&#8217;s of this application could change their time zone within the application, regardless of what the machine was set to. This works fine on the server side, because we were working with UTC dates and stored a time zone preference which could then be used to display the correct date to the user based on their time zone. When we added our flex app into the mix, it became a problem, though, because if we passed the utc date to the flex app, there was no way to format it based on the user&#8217;s time zone, but instead the machine time zone setting. So I came up with a couple of solutions to this problem, none of which is particularly elegant, but I can live with it because I believe they are working around a fundamental flaw in the flash player (ie not being able to configure your time zone from within the vm).</p>
<p>The first solution is to transform your date/time value into it&#8217;s string components, and then parse it into a date object on the client. The server determines the time zone used to get the &#8220;display&#8221; date (as opposed to utc date), and you send the month, date, year, hour, min, sec, etc fields to the client and it gets re-assembled.</p>
<p>The second solution is to find the time zone offset of the client and adjust values based on that. You do this by having your client send a specific known date to the server in UTC. You create a date using the , say 01-01-2000 00:00:00:0, using the year,month,date,hour,minute,second,millisecond constructor of the Date object, and then send the UTC value of that date object to the server. The server does the same thing, but using the specific time zone that you are &#8216;targetting&#8217;. Then you get the utc value of this date, and find the difference between it and what the client sent you. This will give you the time zone offset of the client, which you can send back to the client. Then just roll each date that the server sends to the client by this amount.</p>
<p>This still requires that you touch the data somewhere along the line, either on the server or the client, but there is just no way around it if you want the dates displayed using a time zone other than what the user&#8217;s machine is set to.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
