Bug 54529

Summary: GeolocationPosition to store timestamp as integer in miliseconds
Product: WebKit Reporter: Mahesh Kulkarni <maheshk>
Component: WebKit Misc.Assignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: alex, benjamin, bulach, cshu, diegohcg, hausmann, jarred, jknotten, kenneth, kling, laszlo.gombos, morrita, steveblock, tkent, tonikitoo, yael, zalan, zoltan
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: All   

Description Mahesh Kulkarni 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.
Comment 1 Steve Block 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?
Comment 2 John Knottenbelt 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 ?
Comment 3 Jarred Nicholls 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.
Comment 4 Kent Tamura 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.
Comment 5 Mahesh Kulkarni 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.