Always use timeGetTime() for TimeTicks::Now() on Windows.

Always use timeGetTime() for TimeTicks::Now() on Windows.

This way, we also ensure that timeGetTime() is used for Time::Now(),
and thereby Date.now() even if GetTickCount64() is available.

Also add test coverage for Time::Now(), TimeTicks::Now() and
TimeTicks::HighResNow().

BUG=chromium:288924
TEST=cctest/test-timer

[Benedikt Meurer, 2013-10-01 11:41:56]

Hey Hannes,
Here's the fix for the Date.now() Windows issue. PTAL
-- Benedikt

[Hannes Payer (out of office), 2013-10-02 11:27:25]

Thanks Benedikt, mostly reformatting/renaming nits.

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc
File src/platform/time.cc (right):

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode183
src/platform/time.cc:183: // Check if we need to resynchronize due to backwards
time
Move words up until you hit the 80 chars barrier. Moreover end sentence with a
".".

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode184
src/platform/time.cc:184: // change or elapsed time.
What do you mean here? Should it be "Check if we have to synchronize the clock"?

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode384
src/platform/time.cc:384: virtual bool IsHighResolution() =0;
space missing

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode465
src/platform/time.cc:465: //
http://blogs.msdn.com/b/larryosterman/archive/2009/09/02/what-s-the-differenc...
can we fix that link - 80 chars

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode466
src/platform/time.cc:466: //
remove that // with a newline

https://codereview.chromium.org/25468003/diff/1/src/platform/time.h
File src/platform/time.h (right):

https://codereview.chromium.org/25468003/diff/1/src/platform/time.h#newcode339
src/platform/time.h:339: static bool IsHighResClockWorking();
Can we call it IsHighResolutionClockWorking()? And also rename HighResNow to
HighResolutionNow? Using full names is suggested by the coding style guide.

https://codereview.chromium.org/25468003/diff/1/src/platform/time.h#newcode407
src/platform/time.h:407: int64_t ticks_;
Is it safe to use int64_t here? Shouldn't it be uint64_t?

https://codereview.chromium.org/25468003/diff/1/test/cctest/test-time.cc
File test/cctest/test-time.cc (right):

https://codereview.chromium.org/25468003/diff/1/test/cctest/test-time.cc#newc...
test/cctest/test-time.cc:189: TEST(TimeTicksHighResNowResolution) {
What about merging the last two test cases and using the 1 millisecond
resolution requirement when we have a high resolution clock?

[Benedikt Meurer, 2013-10-02 12:27:46]

PTAL

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc
File src/platform/time.cc (right):

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode183
src/platform/time.cc:183: // Check if we need to resynchronize due to backwards
time
On 2013/10/02 11:27:25, Hannes Payer wrote:
> Move words up until you hit the 80 chars barrier. Moreover end sentence with a
> ".".

Done.

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode184
src/platform/time.cc:184: // change or elapsed time.
On 2013/10/02 11:27:25, Hannes Payer wrote:
> What do you mean here? Should it be "Check if we have to synchronize the
clock"?

Done.

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode384
src/platform/time.cc:384: virtual bool IsHighResolution() =0;
On 2013/10/02 11:27:25, Hannes Payer wrote:
> space missing

Done.

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode465
src/platform/time.cc:465: //
http://blogs.msdn.com/b/larryosterman/archive/2009/09/02/what-s-the-differenc...
On 2013/10/02 11:27:25, Hannes Payer wrote:
> can we fix that link - 80 chars

As discussed offline, this is how we do it in other places.

https://codereview.chromium.org/25468003/diff/1/src/platform/time.cc#newcode466
src/platform/time.cc:466: //
On 2013/10/02 11:27:25, Hannes Payer wrote:
> remove that // with a newline

Done.

https://codereview.chromium.org/25468003/diff/1/src/platform/time.h
File src/platform/time.h (right):

https://codereview.chromium.org/25468003/diff/1/src/platform/time.h#newcode339
src/platform/time.h:339: static bool IsHighResClockWorking();
On 2013/10/02 11:27:25, Hannes Payer wrote:
> Can we call it IsHighResolutionClockWorking()? And also rename HighResNow to
> HighResolutionNow? Using full names is suggested by the coding style guide.

Done.

https://codereview.chromium.org/25468003/diff/1/src/platform/time.h#newcode407
src/platform/time.h:407: int64_t ticks_;
On 2013/10/02 11:27:25, Hannes Payer wrote:
> Is it safe to use int64_t here? Shouldn't it be uint64_t?

int64_t is safe here, and compatible with what Chromium uses.

https://codereview.chromium.org/25468003/diff/1/test/cctest/test-time.cc
File test/cctest/test-time.cc (right):

https://codereview.chromium.org/25468003/diff/1/test/cctest/test-time.cc#newc...
test/cctest/test-time.cc:189: TEST(TimeTicksHighResNowResolution) {
On 2013/10/02 11:27:25, Hannes Payer wrote:
> What about merging the last two test cases and using the 1 millisecond
> resolution requirement when we have a high resolution clock?

TimeTicks::Now() is different from TimeTicks::HighResNow(). Even if we have a
high resolution timer, TimeTicks::Now() will not provide 1ms granularity in
general.

[Hannes Payer (out of office), 2013-10-02 12:44:09]

LGTM

[Benedikt Meurer, 2013-10-02 13:38:35]

This was committed with revision 17080, but SVN returned an error (even tho it
actually did the commit) so the CL was not updated.

https://code.google.com/p/v8/source/detail?r=17080