Assert now > 0 in GetTime GetTimeMillis GetTimeMicros

[pstratem]

Previously all of these functions could return negative values (for different
readons). Large portions of the codebase currently assume that these
functions return positive values.

[pstratem]

(Besides if your time is before 1970-1-1 you will reject every single block as being too far in the future)

[dcousens]

Sure? Concept ACK.
Any motivation for this @pstratem ?

[pstratem]

@dcousens I was reviewing another PR and noticed that it (sort of) relied on this behavior.

Went and looked a bit and noticed basically every caller does.

[dcousens]

utACK

[laanwj]

Anything concerning time deltas is a different issue. I certainly think a monotonic clock would be useful for some measurements (such as pings).

However this code change would just make sure that the absolute time is positive. More of a sanity check of the OS and boost (eg time() returns -1 on error).

[jtimon]

utACK

[sipa]

In what cases do we expect these assertions to fail?

[paveljanik]

IIUIC, it is only for "just to be sure".

E.g. on Linux kernel, you can't make time to fail, especially in the case when NULL is used as an argument. If non-NULL is passed, it can fail when kernel's put_user fails (and in such case, more bad things can happen ;-). The other question is boost...

ACK

[laanwj]

@paveljanik I guess time() could fail if the relevant syscall is somehow blocked off, say, through seccomp_bpf. And yes boost... who knows
All cases in which it's better to fail fast.