This is the reason for the iOS failure in watchLocation. There is code in getCurrentLocation that assumes the timestamp is a Date object and does a
geolocation.lastPosition.timestamp.getTime(). Since iOS is returning the timestamp in milliseconds the .getTime() call fails. I think we can handle this in JavaScript code as long as new Date(DateObjORMilliseconds) works ( pass a Date object or milliseconds to the Date constructor). -becky On Tue, Jun 5, 2012 at 12:44 PM, Simon MacDonald <[email protected]>wrote: > Alright, I have to step out for a bit but I can start creating issues > after that. > > Simon Mac Donald > http://hi.im/simonmacdonald > > > On Tue, Jun 5, 2012 at 12:34 PM, Filip Maj <[email protected]> wrote: > > Yes, do it. It is clearly a mistake on my part. I assumed (!!!!!) that > > domtimestamp === number. > > > > *sad trumpet noise* > > > > On 6/5/12 9:31 AM, "Simon MacDonald" <[email protected]> wrote: > > > >>When I run the geolocation mobile spec tests on Android I get two > >>failures. Both getCurrentPosition and watchPosition complain that > >>p.timestamp is an Object when it expects a number. Well the native > >>Android geolocation API returns a Date object not a timestamp in ms. > >>Looking into the W3C spec for Geolocation the timestamp property of > >>the Position interface should be a DOMTimeStamp [1]. In ECMAScript, > >>the DOMTimeStamp maps to the Date type. > >> > >>So it seems like we have a number of items that we should address: > >> > >>1) Update the geolocation tests to expect timestamp to be a Date. > >>2) Fix the documentation to let people know the timestamp property is > >>a Data and not an integer of type ms. > >>3) Change the native implementations to return Date's not integers. > >> > >>What do you think should I go create JIRA tickets for all these issues? > >> > >>[1] http://www.w3.org/TR/geolocation-API/#position_interface > >>[2] http://www.w3.org/TR/DOM-Level-3-Core/core.html#Core-DOMTimeStamp > >> > >> > >>Simon Mac Donald > >>http://hi.im/simonmacdonald > > >
