Thanks for the contribution! I'd make this calculation on demand. Add a method to the Timer handle get_when(). Also we need tests.

ok instead of calculating the thole thing there you're thinking I should cache the start time (as double instead of the timespec?) and then calculate off of the self.time in get_when, do I understand correctly?

any update @1st1 ? Just looking for a little guidance before I reform my patch

Sorry for the delay! My idea was to do as little work as possible in __cinit__ or __init__, offsetting the bulk of the work to when().

I see, so I need to at a minimum keep the current time I've sampled with timespec_get(...), so one option to avoid any calculation would be to just keep the timespec struct. I didn't go that route because it would require twice the storage as sizeof(timespec) == 16 vs. sizeof(self.when) == 8. Buf if it's your preference to cache the bytes and defer the calculation then I'll change it as you say. Is that your preference?

I think we should call loop.time() when the handle is created and store that time in the handle. The method returns monotonic time that's cached for the current iteration and that's what libuv is using internally to compute the timeouts. Then you'd simply need to add the timeout to that captured creation time in .when()

Also using loop.time() is the only way to get consistency with loop.call_at().

Ok sure, fair enough. That's certainly consistent with the documentation.

Ok, pushed another commit. Works the way you mention and I added one test, not sure what other sort of testing will be worthwhile.