Use time.clock for reactor and other scheduling on windows

[twisted-trac]

	@itamarst reported
Trac ID	trac#416
Type	enhancement
Created	2003-12-01 21:29:29Z

Searchable metadata

``` trac-id__416 416 type__enhancement enhancement reporter__itamarst itamarst priority__lowest lowest milestone__ branch__ branch_author__ status__closed closed resolution__wontfix wontfix component__core core keywords__ time__1070314169000000 1070314169000000 changetime__1477812356437945 1477812356437945 version__ owner__PenguinOfDoom PenguinOfDoom cc__exarkun cc__itamarst cc__PenguinOfDoom cc__teratorn ```

[twisted-trac]

	@itamarst set owner to PenguinOfDoom

Yeah, probably consider doing this in IOCP, if ever.

[twisted-trac]

	@glyph set status to closed

It's not clear that this even makes sense to do. time.clock is deprecated in python 3, anyway. If python wants to make time.time higher resolution, that's fine. But I don't see what the user-facing benefit of this would be. #2424 has a more substantive discussion of potentially cross-platform useful changes to time management within Twisted.

[twisted-trac]

	@itamarst commented

#!html
<pre>
The resolution is much higher.
</pre>

[twisted-trac]

	@itamarst commented

#!html
<pre>
Closed, unless there are any other places you can think of.
</pre>

[twisted-trac]

	@exarkun commented

#!html
<pre>
Reverted to time.time, because time.clock has a period of 49 days.

A possibly way to deal with this:

class Clock:
    lastValue = 0
    rollOver = 0
    INFINITY = 2 ** 16 - 1

    def clock(self):
        v = time.clock()
        if v &lt; self.lastValue - self.INFINITY:
            self.rollOver += 1
            v = v + self.rollOver * self.lastValue
        self.lastValue = v
        return v
</pre>

[twisted-trac]

	@exarkun commented

#!html
<pre>
I don't even care about Windows!

I think we decided not to do this.  IOCP can provide a better IReactorTime or
something.  Resolve unless you disagree.  Or maybe assign to PoD.
</pre>

[twisted-trac]

	@exarkun commented

I can't find any evidence that time.clock actually has a period of 49 days (at least now, if it ever did). GetTickCount wraps around at around 49 days, but time.clock is implemented using QueryPerformanceCounter on Windows, not GetTickCount.