Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gibson.becky@gmail.com
 designates 209.85.213.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAM1AYQCRmAB9ssM+ipgxqOqPj361Ah4Em+AwHO_nGe=HJkg7Dg@mail.gmail.com>
References: 
 <CAM1AYQCyqNd9pqn1eVmOb5smM37juNXvZKeH_SxXmxAWSnCPpw@mail.gmail.com>
	<CBF382E9.782D%fil@adobe.com>
	<CAM1AYQCRmAB9ssM+ipgxqOqPj361Ah4Em+AwHO_nGe=HJkg7Dg@mail.gmail.com>
Date: Tue, 5 Jun 2012 13:00:22 -0400
Message-ID: 
 <CADjNb+=W-tcz0tSzR5wTeB11-iHPstwDK-zru7UDdroJyDO1Pg@mail.gmail.com>
Subject: Re: Geolocation test failures in Mobile Spec
From: Becky Gibson <gibson.becky@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=20cf300fb37114701504c1bc9662

--20cf300fb37114701504c1bc9662
Content-Type: text/plain; charset=ISO-8859-1

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
<simon.macdonald@gmail.com>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 <fil@adobe.com> 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" <simon.macdonald@gmail.com> 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
> >
>

--20cf300fb37114701504c1bc9662--