<p><code>timereceived</code> is when your client first learned of the transaction. If you sent the transaction, it's the time when you sent the transaction. If you received the transaction, it's when your client first saw the transaction on the network.</p>

<p><code>time</code> can be different from <code>timereceived</code> if you first learned about the transaction by seeing it in a block. This usually happens when your client was offline for a while and you're getting caught up with the block chain. In this case, <code>time</code> will use the block's timestamp if it seems reasonable. Specifically:</p>

<ul>
<li>If the block timestamp is in the future, <code>time</code> will be the same as <code>timereceived</code>.</li>
<li>If the block timestamp is before the latest transaction in the wallet, <code>time</code> will be equal to the time of the latest transaction in the wallet.</li>
<li>Otherwise, the block timestamp will be used.</li>
</ul>

<p>Transaction times don't change, even after a reorg, and new transactions will never have a time earlier than an existing transaction. This was not always the case (old versions preferred to use the block timestamp, which is usually more accurate), but the current method makes it easier to deal with transaction timestamps safely.</p>

CC BY-SA 3.0
2013-07-09T23:33:30.320Z
2013-07-09T23:33:30.320Z
theymos
<p>What is exactly the difference between </p>

<p><code>time</code>, <code>blocktime</code> and <code>timereceived</code></p>

<p>in transaction information returned by Bitcoind JSON RPC API? For example:</p>

<pre><code>{
    "amount": 0.02,
    "blockindex": 45,
    "time": 1306179671,
    "category": "receive",
    "confirmations": 109244,
    "timereceived": 1306179671,
    "address": "1P5xanGEdgPKYNt4BnATambHpbZ2h89bYv",
    "txid": "91eb6cb34b9253cce0ab5da171a0f5aae9d3d36208e23062ba61cd9e21c09a3d",
    "blockhash": "0000000000002e65f5cc554e99c352af958a63f4be663627f2c569e5a996a03a",
    "account": "",
    "blocktime": 1306173564
}
</code></pre>

<transactions><bitcoind><json-rpc>
What is the difference between time, blocktime and timereceived?
Alexey Kalmykov
# What is the difference between time, blocktime and timereceived?

(Asked by: username_0 on 2013-05-09)

What is exactly the difference between

`time`, `blocktime` and `timereceived`

in transaction information returned by Bitcoind JSON RPC API? For example:

```
{
    "amount": 0.02,
    "blockindex": 45,
    "time": 1306179671,
    "category": "receive",
    "confirmations": 109244,
    "timereceived": 1306179671,
    "address": "1P5xanGEdgPKYNt4BnATambHpbZ2h89bYv",
    "txid": "91eb6cb34b9253cce0ab5da171a0f5aae9d3d36208e23062ba61cd9e21c09a3d",
    "blockhash": "0000000000002e65f5cc554e99c352af958a63f4be663627f2c569e5a996a03a",
    "account": "",
    "blocktime": 1306173564
}

```

**Tags:** transactions, bitcoind, json-rpc


---

## 1 answers

### Answer by username_1 on 2013-07-09. Score: 9 | Accepted answer

`timereceived` is when your client first learned of the transaction. If you sent the transaction, it's the time when you sent the transaction. If you received the transaction, it's when your client first saw the transaction on the network.

`time` can be different from `timereceived` if you first learned about the transaction by seeing it in a block. This usually happens when your client was offline for a while and you're getting caught up with the block chain. In this case, `time` will use the block's timestamp if it seems reasonable. Specifically:

* If the block timestamp is in the future, `time` will be the same as `timereceived`.
* If the block timestamp is before the latest transaction in the wallet, `time` will be equal to the time of the latest transaction in the wallet.
* Otherwise, the block timestamp will be used.

Transaction times don't change, even after a reorg, and new transactions will never have a time earlier than an existing transaction. This was not always the case (old versions preferred to use the block timestamp, which is usually more accurate), but the current method makes it easier to deal with transaction timestamps safely.


---

