Figuring out Date Time Zones in Adobe Flex/Actionscript

I was really frustrated the past few weeks when a major clock component of an app kept failing when viewed from different time zones. It was always supposed to show Antarctica time and only that. I searched and searched for definitive examples on the web, but never found what I needed.

At the heart of this is the ActionScript Date Class. It’s unfortunately a very poor implementation. I expected to simply have a property where you give the Class a timezone offset and presto you magically get the time for that location of the world. Silly me. In addition the documentation is incorrect in that the getTime() method does NOT in fact report the time in UTC. And, to make things even more fun, the getTimeZoneOffset() method returns minutes rather than milliseconds.

However, after enough iterations I was finally able to cobble together what seems to be a graceful solution. The trick is to use the getTime() method. Then add the time zone offset in milliseconds. This, in theory, gives you UTC time. Then add or subtract the number of hours in milliseconds for your fixed clock. Oh, and I also used the DateTimeFormatter to beautify everything up. Here’s the code to hopefully save someone else a bunch of additional coding:

var df:DateTimeFormatter = new DateTimeFormatter();
df.useUTC = false;
df.timeStyle = "short";
df.dateStyle = "medium";
var d:Date = new Date();

var millisecondsPerThreeHours:int = 1000 * 60 * 60 * 3; //using a -3 hour UTC offset
var timeZoneOffsetMilliSeconds:Number = d.getTimezoneOffset() * 60 * 1000;

d.setTime(d.getTime() + timeZoneOffsetMilliSeconds - millisecondsPerThreeHours);

var antarcticaTime2:String = d.toString();
antarcticaTimeTextArea.text = df.format(antarcticaTime2);

Live From Antarctica – the final 7th Summit.

Our team just finished a massive 5 weeks push to building an app for the Romero family, and in particular Jordan, to follow him on his climb of the final summit on the continent at the bottom of the world. You can find the app on his home page today https://jordanromero.com, or access it directly here https://edn1.esri.com/antarctica.

It was actually Jordan’s dream to climb the highest summits on the major continents. And, he is now on his way to accomplish all that…and before his 16th birthday during what is considered summer in Antarctica. I’m amazed at what he has done. I can’t help but think about what he might be able to accomplish in the future now that he has accomplished a feat that very few ever do.

The app is capturing live GPS coordinates (altitude, heading, speed, lat/lon), live weather and it also includes a Challenge component that anyone can take to conquer their own 7 summits on their own time by walking, swimming, running or biking.

I encourage you to check out the app and even take the Challenge!

For the techno-geeks reading this, here is some background info on the technology. GPS processing and ArcGIS mapping backend services were built in C#.NET by AL Laframboise. The Challenge service and REST endpoints were built in C#.NET by Nick Furness. I built the the Adobe Flex/ActionScript client application using Adobe FlashBuilder 4.5, and the ArcGIS API for Flex provided the client-side mapping. The look and feel were accomplished by the excellent help of UX engineer Frank Garofalo in Esri Professional Services. The client app uses a custom dependency injection model at the core, and the skins were built using Adobe Catalyst.

Testing Facebook Graph API using Localhost

Yes, you absolutely can test web apps locally that use Facebook’s Graph API. I’ve seen a number of blog posts that tell you this isn’t possible and that you need a a fully qualified domain name (FQDN) such as https://www.xyz.com. But, I’m writing this post to correct that misinformation.

It’s really very simple and I’ve been doing this for a number of years for both JavaScript and Flex apps. When you register your app at https://developer.facebook.com, under the Website field, simply enter the https://localhost/ path where your facebook app resides and test away.

 

I’d call this a best practice for testing Facebook APIs. It doesn’t require an FQDN until you are ready to deploy the final app on a production server.