NEW 54529
GeolocationPosition to store timestamp as integer in miliseconds 
https://bugs.webkit.org/show_bug.cgi?id=54529
Summary GeolocationPosition to store timestamp as integer in miliseconds
Mahesh Kulkarni
Reported 2011-02-15 21:46:39 PST
From bug https://bugs.webkit.org/show_bug.cgi?id=42629, as per comment 15 and 16. John/Jarred proposal to change GeolocationPosition to storing time as an integer number of in milliseconds, to match Geoposition. It would make sense to store in milliseconds so that it is an integer and so that it's the "lowest common denominator" and no chance of precision loss. Not to mention, it's more consistent and understandable given that the DOM spec is talking about milliseconds. We won't have to worry while coding if we're in seconds or milliseconds.
Attachments
Add attachment proposed patch, testcase, etc.
Steve Block
Comment 1 2011-02-16 03:25:09 PST
I think there might be historical/style reasons for using a double for the number of seconds, rather than a long for the number of milliseconds. John, I seem to remember you discussing a similar issue with Sam Weinig?
John Knottenbelt
Comment 2 2011-02-16 03:31:40 PST
Well remembered, Steve. I did ask Sam about this issue in an email, and he told me that it made more sense to use double in the C (as opposed to DOM) APIs since that is what has been historically used. Are there any examples of WebCore using integer milliseconds in non-DOM classes ?
Jarred Nicholls
Comment 3 2011-02-16 04:59:00 PST
(In reply to comment #2) > Well remembered, Steve. I did ask Sam about this issue in an email, and he told me that it made more sense to use double in the C (as opposed to DOM) APIs since that is what has been historically used. > > Are there any examples of WebCore using integer milliseconds in non-DOM classes ? Using a double for style reasons sounds fine to me. I think a different question is, are there any examples of WebCore storing seconds in non-DOM classes where it is actually maintaining (dealing with) milliseconds internally or in the DOM? And why? Just wondering if GeolocationPosition is holding the timestamp in seconds for style reasons as well, or can we avoid the conversion from ms -> sec -> ms.
Kent Tamura
Comment 4 2011-02-16 16:25:12 PST
FYI. Source/WebCore/html/DateComponents.{cpp,h} uses milliseconds in double for consistency with Source/JavaScriptCore/wtf/DateMath.h and JavaScript Date though WebCore basically uses seconds in double.
Mahesh Kulkarni
Comment 5 2011-02-16 19:36:00 PST
(In reply to comment #2) > Well remembered, Steve. I did ask Sam about this issue in an email, and he told me that it made more sense to use double in the C (as opposed to DOM) APIs since that is what has been historically used. > > Are there any examples of WebCore using integer milliseconds in non-DOM classes ? I'm not sure why DOMTimerStamp cant be used in non-dom class? When I grep for it I get few hits. As DOMTimerStamp is long long type, I think its more aligned to have the same data type for holding miliseconds value. Also greping for convertSecondsToDOMTimeStamp() fetched only geolocaiton usecase like, Event where currentTime() is used to store DOMTImerStamp obect. IMO Event.cpp should be calling currentTimeMS() and replace those C type of functions altogether.
Note You need to log in before you can comment on or make changes to this bug.