Time

The time field in the block header indicates the rough time a block was created.

Miners put the current time in the block header when they construct their candidate block. It contains a Unix Timestamp (the number of seconds since 01 January 1970), which is what computer programs typically use to store specific points in time.

For example, the genesis block contains the timestamp 1231006505, which is 03 Jan 2009, 18:15:05.

tool-67e5787acb808

Unix Time

Convert the number of seconds since 1 Jan 1970, 00:00:00 to a date.

Unix Time

0d

Now

Date

0 secs

Block Order

Does block time influence the order of blocks?

The timestamps do not influence the order of blocks in the blockchain.

In fact, it's possible that one block could have an earlier timestamp than a block that came before it in the chain. Here's a fairly recent example:

• Block 790,402 = 19 May 2023, 04:22 (2 minutes "before" the previous block)
• Block 790,401 = 19 May 2023, 04:24

• Block 156,114 = 05 Dec 2011, 06:17 (1 hour 59 minutes "before" the previous block)
• Block 156,113 = 05 Dec 2011, 08:16

So whilst the timestamps are usually fairly accurate, sometimes blocks are not in "chronological" order, and that's perfectly fine.

The timestamp of each block is usually pretty close to the current time, but you shouldn't rely on them to be 100% correct. You'll see "out of order" blocks appear in the blockchain a few times a month, so it's not terribly uncommon.

Requirements

What is the maximum and minimum block time?

The timestamp has to be within a certain range for it to be valid:

• It must be greater than the median time of the last 11 blocks (i.e. the time in the block 6 blocks below).
• It must be less than the network adjusted time +2 hours.

So there is some flexibility in what the timestamp can be. For any newly-mined block, the time field could be anywhere between -1 to +2 hours (roughly) from the actual current time, and it would still be valid.

This flexibility allows for a node to have an incorrect time setting (e.g. mistakes due to Daylight Savings Time), and for latency when transmitting blocks across the network.

There is no mathematical justification for the range being between the median of the last 11 blocks and up to +2 hours into the future. They're "good enough" values that Satoshi chose when they coded the first version of bitcoin, and we still use them today.

Network Adjusted Time

The network adjusted time is your local time plus the median offset of all the nodes you are connected to.

For example:

Local Time = 1685010124

Connected Nodes:
  Node 1     = 1685010121 (-3 seconds)
  Node 2     = 1685010122 (-2 seconds)
  Node 3     = 1685010122 (-2 seconds)
  Node 4     = 1685010125 (+1 second)
  Node 5     = 1685010125 (+1 second)
  Node 6     = 1685010127 (+3 seconds)
  Node 7     = 1685010128 (+3600 seconds)
  Median Offset = +1 second

Network Adjusted Time = 1685010125

Note: This is just a quick example.
Nodes are usually connected to more than 7 peers at a time.

The reason we use network adjusted time is that it's difficult for computers on a decentralized network to agree on the current exact time.

The network adjusted time allows the nodes to agree on a time between them, whilst limiting the ability of any one node from manipulating the "current" agreed time.

Usage

What is the time field in the block header used for?

Besides being a rough indicator of when the block was mined, the block's timestamp has a couple of other uses within bitcoin:

Target Recalculation

The timestamps in block headers are used to work out whether blocks are being mined more quickly or more slowly than expected over a 2016-block period, and the target is adjusted accordingly.

Transaction Locktime

A transaction can include a specific locktime to prevent it from being mined in a block until it's less a valid time field in a block header.

Notes

• Transactions do not have timestamps. A raw transaction does not have a timestamp field. To figure out how "old" a transaction is, you have to find the block it is included in and get the timestamp from there. Alternatively, you could manually keep track of when your node first received the transaction from another node on the network (which is what Bitcoin Core does and is why you can see a transaction's "time" when you run bitcoin-cli getmempoolentry [txid], but this information is only stored temporarily).

Resources

• From where does the 2 hours limitation on bitcoin time stamp come?
• Why don't the timestamps in the block chain always increase?
• mediantime.go – Source code for the network adjusted time calculation in the btcd implementation of Bitcoin. Contains excellent comments.