79

I'm looking to use block.timestamp in one of my contracts and I want to know whether the block.timestamp is seconds like in Python or milliseconds like in Java or some other value?

Also, is it safe to use block.timestamp to check if 30 days is past since the last updated time or something like that?

eth
  • 85,679
  • 53
  • 285
  • 406
etherfaces
  • 1,153
  • 1
  • 9
  • 11
  • 2
    The blocks.timestamp is a Unix time stamp. So, it has the complete information about the date, hours, minutes, and seconds (in UTC) when the block was created. – galahad Aug 08 '16 at 17:39
  • 2
    I thank you for your response. I very much appreciate it and for providing more details and clarifications. – etherfaces Aug 08 '16 at 17:52
  • Please also see this post on the same subject: https://ethereum.stackexchange.com/questions/68064/what-is-the-time-zone-of-the-ethereum-block-chain/68065 – djenning90 Mar 12 '19 at 21:00

4 Answers4

59

From the Solidity documentation (here and here):

... timestamp of the current block in seconds since the epoch

For your other question:

Also, is it safe to use block.timestamp to check if 30 days is past since the last updated time or something like that?

Your question isn't completely clear, but assuming you're questioning the validity of a timestamp over a given period of time, then this previous answer should cover it: Is block.timestamp safe for longer time periods?

Richard Horrocks
  • 37,835
  • 13
  • 87
  • 144
  • 1
    Thanks for pointing out the documentation. I some how missed it it is seconds. Let's say I set a timestamp value: lastUpdated in a previous block. In a future block, I check if the lastUpdated is past 30 days or not to do some action. Would this be a safe check? Assuming that the difference in time difference is reasonable(order of days) and not too close? – etherfaces Aug 08 '16 at 17:42
  • 1
    30 days will work fine. It should be accurate to within a half hour or so at worst – Tjaden Hess Nov 07 '16 at 20:28
  • Worth noting that block.timestamp is only reliable for state-changing functions. NO guarantees that block.timestamp is meaningful for view functions. – GGizmos Nov 27 '22 at 05:19
18

block.timestamp is a uint256 value in seconds since the epoch.

It's safe to compare like:

function f(uint start, uint daysAfter) {
    if (block.timestamp >= start + daysAfter * 1 days) { ... }
}

or

if (block.timestamp > start + 30 days) { ... }

Time units are helpful for some calculations with the caveat:

Take care if you perform calendar calculations using these units, because not every year equals 365 days and not even every day has 24 hours because of leap seconds. Due to the fact that leap seconds cannot be predicted, an exact calendar library has to be updated by an external oracle.

eth
  • 85,679
  • 53
  • 285
  • 406
  • 1
    How do I define "start" variable. Should I just do: uint250 start = 1512918335 ? – FosAvance Dec 10 '17 at 15:05
  • start = block.timestamp (now) or start = 23 days etc – Magno C Jun 20 '21 at 04:36
  • It's not safe to compare in this way, especially for the logic you exhibited, where you're checking that at least a certain minimum amount of time has elapsed, since block.timestamp can be set arbitrarily far in the future, as long as it is greater than the parent timestamp: https://ethereum.stackexchange.com/a/428/82179 https://ethereum.stackexchange.com/a/432/82179 – Luke Hutchison Nov 05 '21 at 01:34
  • 1
    @LukeHutchison https://ethereum.stackexchange.com/questions/5927/how-would-a-miner-cope-with-a-huge-block-time has some answers why block.timestamp doesn't end up being arbitrarily far in the future. – eth Nov 10 '21 at 08:02
  • 1
    @eth looks like some implementations are much stricter than the specification, then. Thanks for the info. – Luke Hutchison Nov 12 '21 at 08:16
6

block.timestamp may not be the correct time as it is set by the miner. Hence depends on the accuracy of the miners clock.

The current block.timestamp has to be more than the parent block.timestamp. This is set in the protocol. Some blocks even have 1s difference.

Blockchain has no clock as it would mean sync of all the nodes and that would be almost impossible to achieve.

Vikram
  • 181
  • 1
  • 4
6

1-timestamp is the unix timestamp so to convert it to normal date use http://www.epochconverter.com/ it indicates when the block was created.

2-to answer if it is safer to use block.timestamp <30 days: yes because the miner could change the timestamp by 900 seconds.

Badr Bellaj
  • 18,780
  • 4
  • 58
  • 75
  • Nice, using this way since I saw your comment. Let me ask you: In case I want to pass the days in the constructor, how can I do this? Do I need to specify days in seconds or its allowed to pass like "1 week" for example? – 0xTheL Sep 27 '22 at 20:39