[DennisP]

True if you're being really fine-grained about it, like using the timestamp as the seed of a random number generator.

However, on the scale of a month, the miners aren't going to be able to mess with you. A block stamped with a significantly incorrect timestamp won't be accepted by other miners.

[Drdrdrq]

Are you sure about that? I was under the impression that there were no checks whatsoever and it's only a goodwill of miners (and lack of incentive to do otherwise) that provides somewhat accurate time.

On the flip side, I'm sure there are/will be oracles for approx. block time, so this is still a solveable issue.

[DennisP]

Here's a spec from 2015:

https://github.com/ethereum/wiki/blob/c02254611f218f43cbb075...

From the block validation section: "Is block.timestamp <= now + 900 and is block.timestamp >= parent.timestamp?"

(In Solidity, block.timestamp is in seconds, and I think that's a direct translation from the underlying opcode, so I assume it's 900 seconds here.)

[Drdrdrq]

I stand corrected - it seems blocks' time must be increasing and must not be more than 15 minutes in the future, according to clocks of validating miners. Thanks, didn't know that!