user43695: 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).

user21052: 
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 explains:



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.

43695: <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>
 21052: <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.stack.imgur.com/VmP29.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/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>
