Here's today's fun-with-mobiles tidbit of pain. The extremely entertaining Geolocation API (entertaining to use, not to read) provides the current timestamp in DOMTimeStamp format along with geoposition responses. But it seems browsers and devices aren't 100% in agreement on either what a DOMTimeStamp is, or what it is when it comes back from a geolocation request.
Take for example, this DOMTimeStamp test case. In Firefox 4, I receive:
Type:number
Value:1301839830719 (13 digits)
Date:Sun Apr 03 2011 16:10:30 GMT+0200 (CEST)My trusty-ish old iPhone 3GS concurs with Firefox.
Type:number
Value:1301839909995 (13 digits)
Date:Sun Apr 03 2011 16:11:49 GMT+0200 (CEST)The iOS simulator for an iPhone4 however, thinks that it's half an hour ago.
Type:number
Value:1301838297961 (13 digits)
Date:Sun Apr 03 2011 15:44:57 GMT+0200 (CEST)All fairly reasonable. But, Chrome 10 decides to take things to the next level:
Type:number
Value:1301837259664648 (16 digits)
Date:Mon Jul 31 43223 23:01:04 GMT+0200 (CEST)That's why I use Chrome. It's like living waaay in the future. The one lesson I've learned from all this is that in the year 43223 we'll still be using JavaScript. Awesome!
One Comment
IE9 uses the 13 digit format too. Chrome is obviously just so far advanced it can tell where you’re going to be in the future…