REGRESSION: Searching commits can highlight wrong data points
authorrniwa@webkit.org <rniwa@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 31 Mar 2015 19:43:45 +0000 (19:43 +0000)
committerrniwa@webkit.org <rniwa@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 31 Mar 2015 19:43:45 +0000 (19:43 +0000)
commitd9af7bb501aae36542ca6b924d30dda422dc4202
tree072b5f66ad3e83c390c39a2e3539be305db77af0
parent5a5546f26bbc0d7351be1c2312da3035809e81f0
REGRESSION: Searching commits can highlight wrong data points
https://bugs.webkit.org/show_bug.cgi?id=143272

Reviewed by Antti Koivisto.

The bug was caused by /api/commits returning commit times with millisecond precision whereas /api/runs
return commit times with only second precision. This resulted in the frontend code to match a commit
with the data point that included the next commit when the millisecond component of commit's timestamp
wasn't identically 0.

This discrepancy was caused by the fact PHP's strtotime only ignores milliseconds and /api/commits
was returning timestamp as string instead of parsing via Database::to_js_time as done in /api/runs
so miliseconds component was only preserved in /api/commits.

Fixed the bug by always using Database::to_js_time to return commit time. Also fixed to_js_time so that
it returns time in milisecond precision.

* public/api/commits.php:
(fetch_commits_between): Use Database::to_js_time for format commit times.
(format_commit): Ditto.
* public/include/db.php:
(Database::to_js_time): Parse and append millisecond component. Ignore sub-milliseconds for simplicity.
* public/v2/data.js:
(CommitLogs.fetchForTimeRange): The commit time is now an integer so don't call "replace" on it.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@182199 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Websites/perf.webkit.org/ChangeLog
Websites/perf.webkit.org/public/api/commits.php
Websites/perf.webkit.org/public/include/db.php
Websites/perf.webkit.org/public/v2/data.js