Remove time-utils

[vorot93]

SystemTime::checked_add and SystemTime::checked_sub have been stable since 1.34.

[parity-cla-bot]

It looks like @vorot93 signed our Contributor License Agreement. :+1:

Many thanks,

Parity Technologies CLA Bot

[ordian]

I'm not sure we should worry about https://en.wikipedia.org/wiki/Year_2038_problem for now, the code will probably change by then.

[niklasad1]

I'm not sure we should worry about https://en.wikipedia.org/wiki/Year_2038_problem for now, the code will probably change by then.

I'm not referring to the 2028 year problem. I mean that a Block's timestamp is an u64 and it may be forged. So, it may cause consensus issues. Whether a node decides that i32::max_value + 10 is overflow and another one decides that it is legit on different platforms.

Still, we might have some plausibility checks on the timestamps but I'm not sure if those catches this.

[vorot93]

What if a block timestamp is forged but still fits i32? This code can't catch this in any way.

[niklasad1]

What if a block timestamp is forged but still fits i32? This code can't catch this in any way.

I was not talking about that just the difference between i32/i64 for SystemTime.

However, actually we check that timestamp is less than now + 15 seconds and reject timestamps further on in the future, see https://github.com/paritytech/parity-ethereum/blob/master/ethcore/verification/src/verification.rs#L339-#L364.

But still, we are doing the checked arithmetics before doing those checks so I don't think we are safe on different platforms. In practice, we should return TimestampOverflow or TemporaryInvalid in such cases because we are still a long time away from year 2028 and I'm not sure exactly on the cases in different engines such as AuRA or Clique.

If somebody can prove how we are sure I'm fine merging it.