<p>In theory there is one block per 10 minutes. That means you should be able to approximate the time of a block n as FIRST_BLOCK_TIME + n*600, where FIRST_BLOCK_TIME is the time of the genesis block, 1231006505.</p>

<p>Of course, that's <em>very</em> approximate, as the average time per block has been consistently less than ten minutes due to increasing block difficulty. In fact, as of writing (block 622719 with timestamp 1585016395), is 19621510 seconds earlier (over 7 months) than what would be predicted by that formula.</p>

<blockquote>
  <p>One method, I am considering is to iterate through the blockchain and generate a database that stores the block height and the UNIX timestamp associated in the block header of the block. Would this be a proper solution to the problem?</p>
</blockquote>

<p>Using the real data is obviously going to be better than any approximating formula. Note that the timestamp of blocks are not necessary the actual time they are mined (in normal circumstances they can be up to 2 hours in the future, and up to approximately 1 hour in the past).</p>

CC BY-SA 4.0
2020-03-24T03:41:22.930Z
Hmmm... what is the time that everyone in the network agrees to? I guess I care about "network time" given your last statement of +2hour/-1hour accuracy. Thank you for your response.  It would be nice however to get a more accurate UNIX time but I'll work with what is given. I just want it to be consistent and deterministic.
LeanMan
CC BY-SA 4.0
2020-03-24T04:25:10.463Z
There is no time agreed upon by the network but the block timestamp. It's wildly inaccurate, but not *wrong*, and it's more than enough for its purpose of existing: adjusting difficulty.
Pieter Wuille
CC BY-SA 4.0
2020-03-24T05:03:04.863Z
OK - appreciate the input!
LeanMan
CC BY-SA 4.0
2020-03-24T06:41:44.503Z
Hi is the time provided by the RPC call GetBlock the timestamp of the block in question?  "time" : ttt,          (numeric) The block time in seconds since epoch (Jan 1 1970 GMT) https://bitcoin.org/en/developer-reference#getblock
LeanMan
CC BY-SA 4.0
2020-03-24T06:42:22.397Z
Yes, that's the block's timestamp.
Pieter Wuille
CC BY-SA 4.0
2020-03-24T06:46:56.410Z
Thank you. And I am slightly confused by your 2nd paragraph, characterizing increasing block difficulty as time between blocks should be correlated with increasing average time between blocks (or set it to the intended 10 minute between blocks). Are you implying that time between blocks has consistently been less than 10 minutes (in this case 1 minute) due to hash-rate outpacing the difficulty formula?
LeanMan
CC BY-SA 4.0
2020-03-24T06:48:53.477Z
Correct. The average block rate over all time is around 1 block per 9.5 minutes.
Pieter Wuille
CC BY-SA 4.0
2020-03-24T07:41:34.717Z
Currrntly, more than 12 minutes.
Claris
CC BY-SA 4.0
2020-03-24T08:41:55.380Z
@LeanMan re: *"what is the time that everyone in the network agrees to?"* - the blockchain *is* the clock, each new block is like one tick forward.
chytrik
CC BY-SA 4.0
2020-03-24T02:30:08.897Z
2020-03-24T07:23:56.453Z
2020-03-24T07:23:56.453Z
Pieter Wuille
<p>I want to create a converter that can be given a block height, human readable time, or UNIX time and then provide the correlated information for it. For example, if given a block height, the converter will give you an estimated time (UNIX and converted to human readable format). And the same if given a UNIX time, it'll provide block height and human readable time associated with that block. And so forth if given a human readable string (stretch goal). </p>

<p>However, looking at the information online it seems pretty lack luster and also very approximate, using formulas, etc. See links here of similar questions: </p>

<p><a href="https://ethereum.stackexchange.com/questions/10576/calculate-approximative-block-height-at-a-certain-time">https://ethereum.stackexchange.com/questions/10576/calculate-approximative-block-height-at-a-certain-time</a></p>

<p><a href="https://www.reddit.com/r/BitcoinBeginners/comments/87lr89/is_there_any_block_height_to_datetime_converter" rel="nofollow noreferrer">https://www.reddit.com/r/BitcoinBeginners/comments/87lr89/is_there_any_block_height_to_datetime_converter</a></p>

<p>Are there any methods that could be achieved to create a deterministic result?</p>

<p>One method, I am considering is to iterate through the blockchain and generate a database that stores the block height and the UNIX timestamp associated in the block header of the block. Would this be a proper solution to the problem? </p>

<blockchain><height>
How to create block height to UNIX time converter?
LeanMan
# How to create block height to UNIX time converter?

(Asked by: username_0 on 2020-03-23)

I want to create a converter that can be given a block height, human readable time, or UNIX time and then provide the correlated information for it. For example, if given a block height, the converter will give you an estimated time (UNIX and converted to human readable format). And the same if given a UNIX time, it'll provide block height and human readable time associated with that block. And so forth if given a human readable string (stretch goal).

However, looking at the information online it seems pretty lack luster and also very approximate, using formulas, etc. See links here of similar questions:

<https://ethereum.stackexchange.com/questions/10576/calculate-approximative-block-height-at-a-certain-time>

<https://www.reddit.com/r/BitcoinBeginners/comments/87lr89/is_there_any_block_height_to_datetime_converter>

Are there any methods that could be achieved to create a deterministic result?

One method, I am considering is to iterate through the blockchain and generate a database that stores the block height and the UNIX timestamp associated in the block header of the block. Would this be a proper solution to the problem?

**Tags:** blockchain, height


---

## 1 answers

### Answer by username_1 on 2020-03-24. Score: 4 | Accepted answer

In theory there is one block per 10 minutes. That means you should be able to approximate the time of a block n as FIRST\_BLOCK\_TIME + n\*600, where FIRST\_BLOCK\_TIME is the time of the genesis block, 1231006505.

Of course, that's *very* approximate, as the average time per block has been consistently less than ten minutes due to increasing block difficulty. In fact, as of writing (block 622719 with timestamp 1585016395), is 19621510 seconds earlier (over 7 months) than what would be predicted by that formula.

> One method, I am considering is to iterate through the blockchain and generate a database that stores the block height and the UNIX timestamp associated in the block header of the block. Would this be a proper solution to the problem?

Using the real data is obviously going to be better than any approximating formula. Note that the timestamp of blocks are not necessary the actual time they are mined (in normal circumstances they can be up to 2 hours in the future, and up to approximately 1 hour in the past).

> **Comments:**
> **username_0**: Hmmm... what is the time that everyone in the network agrees to? I guess I care about "network time" given your last statement of +2hour/-1hour accuracy. Thank you for your response.  It would be nice however to get a more accurate UNIX time but I'll work with what is given. I just want it to be consistent and deterministic.  
> **username_1**: There is no time agreed upon by the network but the block timestamp. It's wildly inaccurate, but not *wrong*, and it's more than enough for its purpose of existing: adjusting difficulty.  
> **username_0**: OK - appreciate the input!  
> **username_0**: Hi is the time provided by the RPC call GetBlock the timestamp of the block in question?  "time" : ttt,          (numeric) The block time in seconds since epoch (Jan 1 1970 GMT) https://bitcoin.org/en/developer-reference#getblock  
> **username_1**: Yes, that's the block's timestamp.  
> **username_0**: Thank you. And I am slightly confused by your 2nd paragraph, characterizing increasing block difficulty as time between blocks should be correlated with increasing average time between blocks (or set it to the intended 10 minute between blocks). Are you implying that time between blocks has consistently been less than 10 minutes (in this case 1 minute) due to hash-rate outpacing the difficulty formula?  
> **username_1**: Correct. The average block rate over all time is around 1 block per 9.5 minutes.  
> **username_2**: Currrntly, more than 12 minutes.  
> **username_3**: @username_0 re: *"what is the time that everyone in the network agrees to?"* - the blockchain *is* the clock, each new block is like one tick forward.  

---

