<blockquote>
  <p>I am speculating, at this point, that these transactions that have no time associated with them are unconfirmed? Is this understanding correct?</p>
</blockquote>

<p>Yes.  The <a href="https://bitcoin.org/en/developer-reference#getrawtransaction" rel="nofollow noreferrer">Bitcoin.org Developer Reference</a> explains:</p>

<blockquote>
  <p><a href="https://i.sstatic.net/VmP29.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/VmP29.png" alt="enter image description here"></a></p>
</blockquote>

<p>The reason for this is that transaction themselves don't contain a time field, so the only times that can be used are either (1) when the node first received the transaction or (2) the time field from a block that includes the transaction.</p>

<p>Bitcoin Core does keep track of #1 but it doesn't display it in the <code>getrawtransaction</code> RPC output.  If you need it, you can get it from the <code>getrawmempool</code> RPC (try calling that RPC with the parameter <code>true</code>).  Note that the time can change if a transaction is evicted from the mempool (due to age or low fees) and then later re-added.</p>

CC BY-SA 3.0
2017-03-28T19:07:17.463Z
You can also use `getmempoolentry <txid>` since 0.13.0, I think.
Pieter Wuille
CC BY-SA 3.0
2017-03-28T16:16:28.240Z
2017-03-28T16:16:28.240Z
David A. Harding
<p>I have been calling the HTTP method <code>getrawtransaction</code> for a while now to retrieve raw transactions. It used to be, until recently, that I would get the <code>time</code> field with every transaction. However, in the last few days, I noticed that this field is no longer present with some transactions. What happened with this field?</p>

<p>Here is an example that does have the <code>time</code> field/value: <code>/usr/local/bin/bitcoin-cli getrawtransaction b6a26cc6d1573473724ad3bd49b16a33a69a738f4d1eb9e5992e39ec0be086a9 1</code></p>

<pre><code>{
  "result":{
    "hex":"01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4b03e8d0030551fdc4495efabe6d6d7a81d2b72c3811f3a24b5a5d4431f46d284993aa067a25ec6abdb030209eacb8010000000000000000454d432055533200d0298378097f0000a19d0000ffffffff01b11d0096000000001976a914740ecaf436d5867903c722d783fc994c25a29b1588ac00000000",
    "txid":"b6a26cc6d1573473724ad3bd49b16a33a69a738f4d1eb9e5992e39ec0be086a9",
    "hash":"b6a26cc6d1573473724ad3bd49b16a33a69a738f4d1eb9e5992e39ec0be086a9",
    "size":160,
    "vsize":160,
    "version":1,
    "locktime":0,
    "vin":[
      {
        "coinbase":"03e8d0030551fdc4495efabe6d6d7a81d2b72c3811f3a24b5a5d4431f46d284993aa067a25ec6abdb030209eacb8010000000000000000454d432055533200d0298378097f0000a19d0000",
        "sequence":4294967295
      }
    ],
    "vout":[
      {
        "value":25.16590001,
        "n":0,
        "scriptPubKey":{
          "asm":"OP_DUP OP_HASH160 740ecaf436d5867903c722d783fc994c25a29b15 OP_EQUALVERIFY OP_CHECKSIG",
          "hex":"76a914740ecaf436d5867903c722d783fc994c25a29b1588ac",
          "reqSigs":1,
          "type":"pubkeyhash",
          "addresses":[
            "1Baf75Ferj6A7AoN565gCQj9kGWbDMHfN9"
          ]
        }
      }
    ],
    "blockhash":"000000000000003d8ec00e2cbaf8090697b1598abe1e209960e55f0884d6044e",
    "confirmations":10,
    "time":1375585378,
    "blocktime":1375585378
  },
  "id":"bitcoin"
}
</code></pre>

<p>Here is an example that does not have the <code>time</code> field/value: <code>/usr/local/bin/bitcoin-cli getrawtransaction 0a5c687bafb7f5008028efc4dcdd510c15be86347b0607e5bf461f211ecbaf78 1</code>.</p>

<pre><code>{
  "result": {
    "hex": "010000000153af347ad5e3c28296b7fc833a02612dbf9a5b76752133b18fd51a532803556c010000006a473044022052622e673e12298315553671df71c4795a5baffb5992ae2b90a95f84539a8d9302200c81def7655facab2f3860345a9b35fe157e2b08b27721f7af49c5ec80483d9a012103628a2f0c158be42a1c8ce37dfffd9951dd3c8bf9ca13e592b864e46784cc9ebffeffffff0292cf032f070000001976a914df01a3394df97f114943a8e37ada789ea6d7bef788ac00e1f505000000001976a9141e5e089913ff694d2f3f3b8ed1ec1e24bdc311c488ac1f020700",
    "txid": "0a5c687bafb7f5008028efc4dcdd510c15be86347b0607e5bf461f211ecbaf78",
    "hash": "0a5c687bafb7f5008028efc4dcdd510c15be86347b0607e5bf461f211ecbaf78",
    "size": 225,
    "vsize": 225,
    "version": 1,
    "locktime": 459295,
    "vin": [
      {
        "txid": "6c550328531ad58fb1332175765b9abf2d61023a83fcb79682c2e3d57a34af53",
        "vout": 1,
        "scriptSig": {
          "asm": "3044022052622e673e12298315553671df71c4795a5baffb5992ae2b90a95f84539a8d9302200c81def7655facab2f3860345a9b35fe157e2b08b27721f7af49c5ec80483d9a[ALL] 03628a2f0c158be42a1c8ce37dfffd9951dd3c8bf9ca13e592b864e46784cc9ebf",
          "hex": "473044022052622e673e12298315553671df71c4795a5baffb5992ae2b90a95f84539a8d9302200c81def7655facab2f3860345a9b35fe157e2b08b27721f7af49c5ec80483d9a012103628a2f0c158be42a1c8ce37dfffd9951dd3c8bf9ca13e592b864e46784cc9ebf"
        },
        "sequence": 4294967294
      }
    ],
    "vout": [
      {
        "value": 308.5354997,
        "n": 0,
        "scriptPubKey": {
          "asm": "OP_DUP OP_HASH160 df01a3394df97f114943a8e37ada789ea6d7bef7 OP_EQUALVERIFY OP_CHECKSIG",
          "hex": "76a914df01a3394df97f114943a8e37ada789ea6d7bef788ac",
          "reqSigs": 1,
          "type": "pubkeyhash",
          "addresses": [
            "1ML9eZVM3NTLvM25w4eYfWLQC9gHwRuBJb"
          ]
        }
      },
      {
        "value": 1,
        "n": 1,
        "scriptPubKey": {
          "asm": "OP_DUP OP_HASH160 1e5e089913ff694d2f3f3b8ed1ec1e24bdc311c4 OP_EQUALVERIFY OP_CHECKSIG",
          "hex": "76a9141e5e089913ff694d2f3f3b8ed1ec1e24bdc311c488ac",
          "reqSigs": 1,
          "type": "pubkeyhash",
          "addresses": [
            "13mZvKjZ3TtzfL7z4EqsG5sMNWayzjNHtY"
          ]
        }
      }
    ]
  },
  "error": null,
  "id": "bitcoin"
}
</code></pre>

<p>I noticed that this is happening for newer and incoming bitcoin transactions, but not older ones. One key difference between the two JSON output is that the transaction with <code>time</code> and <code>blocktime</code> field/value also has <code>confirmations</code> and <code>blockhash</code>. The way I am getting these bitcoin transactions is that I listen to the <code>zmq</code> port, and once a transaction's hash comes through, I then call the HTTP method <code>getrawtransaction</code> to decode the hash. I do notice that if I wait a while or keep trying to call <code>getrawtransaction</code> (e.g. press the up arrow key + enter multiple times over a duration of a few seconds), then the transaction JSON returned eventually does have the <code>time</code> field/value populated.</p>

<p>I am speculating, at this point, that these transactions that have no <code>time</code> associated with them are unconfirmed? Is this understanding correct? </p>

<p>If my understanding is correct, that some transactions do not have a <code>time</code> associated with them because they are unconfirmed, when they do become confirmed, are they rebroadcasted through the network (e.g. via zmq) so that I have another chance to get them? </p>

<p>Please note, I am not trying to create or manipulate data, just simply listen to incoming new transactions and parse them. One of my logic centers around the <code>time</code> field, and since I've noticed not all transactions have this field, that code "breaks" (since the assumption is that all decoded transactions will have such a field/value).</p>

<transactions><bitcoind><unconfirmed-transactions><raw-transaction><zeromq>
What happened to the "time" (and blocktime) field of raw transactions?
Jane Wayne
# What happened to the "time" (and blocktime) field of raw transactions?

(Asked by: username_0 on 2017-03-28)

I have been calling the HTTP method `getrawtransaction` for a while now to retrieve raw transactions. It used to be, until recently, that I would get the `time` field with every transaction. However, in the last few days, I noticed that this field is no longer present with some transactions. What happened with this field?

Here is an example that does have the `time` field/value: `/usr/local/bin/bitcoin-cli getrawtransaction b6a26cc6d1573473724ad3bd49b16a33a69a738f4d1eb9e5992e39ec0be086a9 1`

```
{
  "result":{
    "hex":"01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4b03e8d0030551fdc4495efabe6d6d7a81d2b72c3811f3a24b5a5d4431f46d284993aa067a25ec6abdb030209eacb8010000000000000000454d432055533200d0298378097f0000a19d0000ffffffff01b11d0096000000001976a914740ecaf436d5867903c722d783fc994c25a29b1588ac00000000",
    "txid":"b6a26cc6d1573473724ad3bd49b16a33a69a738f4d1eb9e5992e39ec0be086a9",
    "hash":"b6a26cc6d1573473724ad3bd49b16a33a69a738f4d1eb9e5992e39ec0be086a9",
    "size":160,
    "vsize":160,
    "version":1,
    "locktime":0,
    "vin":[
      {
        "coinbase":"03e8d0030551fdc4495efabe6d6d7a81d2b72c3811f3a24b5a5d4431f46d284993aa067a25ec6abdb030209eacb8010000000000000000454d432055533200d0298378097f0000a19d0000",
        "sequence":4294967295
      }
    ],
    "vout":[
      {
        "value":25.16590001,
        "n":0,
        "scriptPubKey":{
          "asm":"OP_DUP OP_HASH160 740ecaf436d5867903c722d783fc994c25a29b15 OP_EQUALVERIFY OP_CHECKSIG",
          "hex":"76a914740ecaf436d5867903c722d783fc994c25a29b1588ac",
          "reqSigs":1,
          "type":"pubkeyhash",
          "addresses":[
            "1Baf75Ferj6A7AoN565gCQj9kGWbDMHfN9"
          ]
        }
      }
    ],
    "blockhash":"000000000000003d8ec00e2cbaf8090697b1598abe1e209960e55f0884d6044e",
    "confirmations":10,
    "time":1375585378,
    "blocktime":1375585378
  },
  "id":"bitcoin"
}

```

Here is an example that does not have the `time` field/value: `/usr/local/bin/bitcoin-cli getrawtransaction 0a5c687bafb7f5008028efc4dcdd510c15be86347b0607e5bf461f211ecbaf78 1`.

```
{
  "result": {
    "hex": "010000000153af347ad5e3c28296b7fc833a02612dbf9a5b76752133b18fd51a532803556c010000006a473044022052622e673e12298315553671df71c4795a5baffb5992ae2b90a95f84539a8d9302200c81def7655facab2f3860345a9b35fe157e2b08b27721f7af49c5ec80483d9a012103628a2f0c158be42a1c8ce37dfffd9951dd3c8bf9ca13e592b864e46784cc9ebffeffffff0292cf032f070000001976a914df01a3394df97f114943a8e37ada789ea6d7bef788ac00e1f505000000001976a9141e5e089913ff694d2f3f3b8ed1ec1e24bdc311c488ac1f020700",
    "txid": "0a5c687bafb7f5008028efc4dcdd510c15be86347b0607e5bf461f211ecbaf78",
    "hash": "0a5c687bafb7f5008028efc4dcdd510c15be86347b0607e5bf461f211ecbaf78",
    "size": 225,
    "vsize": 225,
    "version": 1,
    "locktime": 459295,
    "vin": [
      {
        "txid": "6c550328531ad58fb1332175765b9abf2d61023a83fcb79682c2e3d57a34af53",
        "vout": 1,
        "scriptSig": {
          "asm": "3044022052622e673e12298315553671df71c4795a5baffb5992ae2b90a95f84539a8d9302200c81def7655facab2f3860345a9b35fe157e2b08b27721f7af49c5ec80483d9a[ALL] 03628a2f0c158be42a1c8ce37dfffd9951dd3c8bf9ca13e592b864e46784cc9ebf",
          "hex": "473044022052622e673e12298315553671df71c4795a5baffb5992ae2b90a95f84539a8d9302200c81def7655facab2f3860345a9b35fe157e2b08b27721f7af49c5ec80483d9a012103628a2f0c158be42a1c8ce37dfffd9951dd3c8bf9ca13e592b864e46784cc9ebf"
        },
        "sequence": 4294967294
      }
    ],
    "vout": [
      {
        "value": 308.5354997,
        "n": 0,
        "scriptPubKey": {
          "asm": "OP_DUP OP_HASH160 df01a3394df97f114943a8e37ada789ea6d7bef7 OP_EQUALVERIFY OP_CHECKSIG",
          "hex": "76a914df01a3394df97f114943a8e37ada789ea6d7bef788ac",
          "reqSigs": 1,
          "type": "pubkeyhash",
          "addresses": [
            "1ML9eZVM3NTLvM25w4eYfWLQC9gHwRuBJb"
          ]
        }
      },
      {
        "value": 1,
        "n": 1,
        "scriptPubKey": {
          "asm": "OP_DUP OP_HASH160 1e5e089913ff694d2f3f3b8ed1ec1e24bdc311c4 OP_EQUALVERIFY OP_CHECKSIG",
          "hex": "76a9141e5e089913ff694d2f3f3b8ed1ec1e24bdc311c488ac",
          "reqSigs": 1,
          "type": "pubkeyhash",
          "addresses": [
            "13mZvKjZ3TtzfL7z4EqsG5sMNWayzjNHtY"
          ]
        }
      }
    ]
  },
  "error": null,
  "id": "bitcoin"
}

```

I noticed that this is happening for newer and incoming bitcoin transactions, but not older ones. One key difference between the two JSON output is that the transaction with `time` and `blocktime` field/value also has `confirmations` and `blockhash`. The way I am getting these bitcoin transactions is that I listen to the `zmq` port, and once a transaction's hash comes through, I then call the HTTP method `getrawtransaction` to decode the hash. I do notice that if I wait a while or keep trying to call `getrawtransaction` (e.g. press the up arrow key + enter multiple times over a duration of a few seconds), then the transaction JSON returned eventually does have the `time` field/value populated.

I am speculating, at this point, that these transactions that have no `time` associated with them are unconfirmed? Is this understanding correct?

If my understanding is correct, that some transactions do not have a `time` associated with them because they are unconfirmed, when they do become confirmed, are they rebroadcasted through the network (e.g. via zmq) so that I have another chance to get them?

Please note, I am not trying to create or manipulate data, just simply listen to incoming new transactions and parse them. One of my logic centers around the `time` field, and since I've noticed not all transactions have this field, that code "breaks" (since the assumption is that all decoded transactions will have such a field/value).

**Tags:** transactions, bitcoind, unconfirmed-transactions, raw-transaction, zeromq


---

## 1 answers

### Answer by username_1 on 2017-03-28. Score: 2 | Accepted answer

> I am speculating, at this point, that these transactions that have no time associated with them are unconfirmed? Is this understanding correct?

Yes. The [Bitcoin.org Developer Reference](https://bitcoin.org/en/developer-reference#getrawtransaction) explains:

> [![enter image description here](https://i.sstatic.net/VmP29.png)](https://i.sstatic.net/VmP29.png)

The reason for this is that transaction themselves don't contain a time field, so the only times that can be used are either (1) when the node first received the transaction or (2) the time field from a block that includes the transaction.

Bitcoin Core does keep track of #1 but it doesn't display it in the `getrawtransaction` RPC output. If you need it, you can get it from the `getrawmempool` RPC (try calling that RPC with the parameter `true`). Note that the time can change if a transaction is evicted from the mempool (due to age or low fees) and then later re-added.

> **Comments:**
> **username_2**: You can also use `getmempoolentry <txid>` since 0.13.0, I think.  

---

