A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
29

Not especially, but it depends on what the use case is. Block times are subject to the following constraints: If you stamp your block with a time too far in the future, no one else will build on it (miners will not build on a block timestamped "from the future"). Your block time cannot be stamped with an earlier time than its parent. Difficulty is kept ...


24

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 ...


20

Within the Ethereum Virtual Machine, there isn't a way to get the current time, other than the block time. So there is no way to get it in Solidity. Why? There is disagreement between computers about what the current time is, and Ethereum needs to run every transaction with exactly the same outcome on every node. What next? Outline what you're trying to ...


18

Ethereum nodes (regardless of mining) need to have an accurate time, otherwise they will not be able to connect to peers and to the network (https://github.com/ethereum/go-ethereum/wiki/Connecting-to-the-network). Small differences in time are tolerated by nodes, but as one node's time gets further away from Coordinated UTC Time (per NTP), its number of ...


14

Yes, you can guarantee long run time accuracy. Miners can't cheat that much to change the timestamp over days. Blocktime is adjusted to be constant within certain error margins, and timestamps is guaranteed to be rejected if they are excessive. Serenity and PoS 'proven' until core team decides otherwise. It is very very unlikely to happen, what reason could ...


13

First, a basic: using strict equality == block.timestamp would not be safe, since a block with that exact timestamp may never get mined. So use >= block.timestamp Now it depends on what happens when the contract "expiration time" is reached. For reasons similar to the safe use of BLOCKHASH, block.timestamp should only be safely used if the total amount ...


13

When a transaction is executed, it is done in the context of being part of a block. The block includes a timestamp (in seconds since 1970), which your contract code can refer to by the name now. The timestamp is set by the miner who mines the block and nobody can be sure at what time they really mined it, so it may not be exactly accurate. However, it must ...


12

The block number will always be correct by definition: It's number x in the chain, because it's chained on top of x-1. However, as you say block.timestamp can be gamed a little bit - or with the cooperation of the economic majority of validating nodes a lot - which also means that the relationship of block.number to actual time can be gamed. So if you don't ...


11

A Transaction doesn't have a timestamp. However, Every block provides a timestamp(when it was collected), but if the time is critical for you don't refer to this timestamp because a miner could modify it by about 900s you could use instead block.number. 1- current block timestamp is returned by now : e.g contract Test { function Time_call() returns (...


10

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 ...


10

15 April 2016 10:00 UTC translates to 1460714400 in Unix Timestamp. I never used it but there is this library by @pipermerriam called ethereum-datetime, so you could call his contract to get what you want


9

block_timestamp CANNOT be before parent_timestamp This is enforced by the protocol, see yellow paper: Hs is the timestamp of block H and must fulfil the relation: (48) Hs > P(H)Hs Also in my empirical research on Homesteads blocktimes there was not a single negative value.


8

Just to elaborate on Dennis' answer and explain why this hindrance exists. Deep down, the decentralized nature of the consensus means that no one's clock is any better than anyone else'. Blocks disambiguate transaction order which is critical for reaching consensus about world state. They do this without reference to a reliable time source. Since no one ...


8

now is a Solidity special variable, which equates to the current time since the epoch, in seconds. From the documentation (linked above): now (uint): current block timestamp (alias for block.timestamp)


7

Here's the code I've found so far that deals with syncing time. It uses pool.ntp.org:123 as the time syncing source. From Go Ethereum - p2p/discover/ntp.go, lines 48-65: func checkClockDrift() { drift, err := sntpDrift(ntpChecks) if err != nil { return } if drift < -driftThreshold || drift > driftThreshold { warning := ...


7

You have to code it into your contract either by saving the block.timestamp in the constructor: contract A { uint public createdTimestamp; function A() { createdTimestamp = block.timestamp; } } which you can access like this: contract B is Test { function testTimestamp () { A a = new A(); uint timestamp = a.createdTimestamp(); //@...


7

If you are using geth here's a patch that I use to accelerate mining. You could probably modify it to decelerate mining if you wish. (I'm curious why you wish to go slower). In any event, I think the answer to "how does the interval for mining get set" is "not very clear from the code"... but this patch should give you a head start in understanding the ...


6

If you just mean a general formula, rather than something written in Solidity... Something along the lines of: last_block_number + ((future_time - time_now) / block_time) Where the future_time and time_now are in seconds since the epoch, and block_time is the average expected block time. The block time is currently hovering between 14 and 14.5 seconds. ...


6

It depends on how fine-grained you need to be. The timestamp has to have a later time than the previous block's timestamp, and if it's too inaccurate then other miners will reject it. So if your contract has to count days, and two years from now it will still be running and counting days, then timestamps are probably the way to go. You'll have to think ...


5

No, In solidty there is no Date object which will give you the actual time, we can only get the timestamp of the block in which the contract is invoked, which is deterministic. You can use now keyword or block.timestamp in solidity to get the timestamp of the current block. This can be used to work with time. Reference to an auction contract is here.


5

It's the timestamp of the current block. The idea is like this: When a miner mines a block, he/she picks the timestamp, executes all contracts with the chosen timestamp to update the state, and does the searching. Thus, now is the timestamp of the current block.


5

TL;DR: Blocks must be within reasonable Unix time or they will be rejected. The yellow paper states: timestamp: A scalar value equal to the reasonable output of Unix’s time() at this block’s inception; formally Hs. The white paper says: The basic block validation algorithm in Ethereum is as follows: [...] Check that the timestamp of ...


5

As mentioned, the protocol prevents this from happening. As for miners' clocks, the protocol can't tell what their actual clock says. A miner could simply lie, put a different timestamp in, and the protocol would be none-the-wiser. The protocol attempts to prevent this by the difficulty adjustment formula. To quote the Yellow Paper: This mechanism ...


5

The miner could cheat in the timestamp by a tolerance of 900 seconds. so if you check outside this intervall you are safe.


5

The block.timestamp should indicate approximately when the block was mined. But it is only an approximation, it depends on the precision of the clock of the machines working on it, also a miner can modify it. So it is not a very secure measure of the time but for your use case should be good. From solidity documentation block.timestamp (uint): current ...


5

It's worth noting that miners can manipulate now and so it shouldn't be relied upon for anything sensitive such as seeding Psuedo-Random Number Generators.


4

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.


4

Universal Hash Time is a proof of existence service that you can build on top of a blockchain. To further answer your questions: Purpose: it proves that some data existed at the time a block that includes the hash of the said data was generated Problem solved: proof of existence can be a service in itself, but it can also enable broader services such as ...


4

I've been making my contracts descend from a simple contract that has a currTime() function and a testing boolean. If I set testing to true, currTime() returns a fake time, which I can manipulate with functions like addDays(uint days). If testing is false, then currTime() just returns block.timestamp. Every place where I'd check the timestamp, I call ...


4

If you're looking at something happening days in advance you should probably stop worrying and just use block.timestamp. See this discussion on how much you should worry about miner manipulation: Solidity: Timestamp dependency, is it possible to do safely? If you're looking at an outcome within a few minutes, you should probably also require a minimum block....


Only top voted, non community-wiki answers of a minimum length are eligible