Openzeppelin-contracts: Date utility

[martriay]

Smart contracts have to deal with dates for a multiplicity of reasons. Nowadays this is not only done by placing a magic constant but also by representing them as seconds since unix epoch, which is not human-readable and error prone.

Smart contract programming is no different discipline from "regular" software programming as we tend to refactor existing code or change our minds on a given functionality. When this happens, arbitrary numbers representing old dates are difficult to catch.

To address this issue I suggest a Date utility for defining dates in a human-readable manner following javascript's Date interface as it's something we're used to.

Thus if we wanted to state that a given crowdsale starts on October 31st at 16:30 UTC, we would write it like this:

uint256 crowdsaleStartsAt = Date(2017, 9, 31, 16, 30)

Opening up the topic for discussion.

[federicobond]

@martriay I don't think this can be done efficiently with a library, but it looks like it could be a good addition to the base Solidity language. Would you mind opening an issue there?

[ernestas2k]

Could you point me to successful uses (if any) of dates/timestamps in smart contracts?
To my best knowledge, timestamp is easily manipulated by miners, which makes them unusable (in many cases).
For instance:

when mining a block, a miner has to set the timestamp for the block (Figure 2). Normally, the timestamp is set as the current time of the miner’s local system. However, the miner can vary this value by roughly 900 seconds, while still having other miners accept the block… Thus, the adversary can choose different block timestamps to manipulate the outcome of timestamp-dependent contracts.

(https://blog.acolyer.org/2017/02/23/making-smart-contracts-smarter/)

[federicobond]

They are not unusable for many cases. You just have to be careful where you use them.

[martriay]

As @federicobond said, there are several non-critical use cases (as long as they can resist a 900s error). That being said, dates represented in uint256 are very common in today's smart contracts and I think we need to minimize the margin of error.

[nventuro]

Hm, interesting. Closing this issue though to merge it with https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1531.