<p>I've also had the same issue whereby importing a private key using RPC Console <em>importprivkey</em> will rescan and <strong>tag it with the time which the rescan takes place</strong> in btc-qt. </p>

<p>Even Multibit which uses the following format for private key (*.key) files is only dated such that <strong>the date corresponds to what is assumed to be the key's creation date</strong>:
Kwnononok7xQwSNIPSNIPSNIPSNIPssthcheckth1s 2013-09-18T09:42:28Z</p>

<p>As mentioned, the Blockchain is not being consulted for transaction history - a major flaw IMO.</p>

CC BY-SA 4.0
2019-01-27T02:31:49.157Z
I just ran into this again _today_!
Michael Hampton
CC BY-SA 3.0
2013-12-21T11:38:17.783Z
2013-12-21T11:38:17.783Z
Wizard Of Ozzie
<p>Any ideas about this one? I've imported addresses into my wallet and on rescan, all transactions come up as same date and time?</p>

CC BY-SA 3.0
2013-04-18T00:35:40.663Z
The transaction data in the blockchain doesn't have timestamps, but the client knows when it sent a transaction so that is what normally will be added to the transaction. Since the client is learning of these transactions from the blockchain, perhaps the block timestamp should be used instead of the time the rescan occurs.
Stephen Gornick
CC BY-SA 3.0
2013-04-18T00:39:35.560Z
Ah, thanks. Yeah I'm surprised it doesn't use the block timestamp in the case of rescanning. Oh well... version 0.9 ?!
pinhead
CC BY-SA 3.0
2013-04-18T07:29:52.443Z
@StephenGornick post it as an answer!
eMansipater
CC BY-SA 3.0
2014-01-21T03:27:55.073Z
Shouldn't this be considered a bug? I can see a very valid case for opening a request for change to the Qt client!
Joe Pineda
<bitcoin-core>
Bitcoin-Qt listing all Transactions as occurring at same date and time
pinhead
# Bitcoin-Qt listing all Transactions as occurring at same date and time

(Asked by: username_0 on 2013-04-18)

Any ideas about this one? I've imported addresses into my wallet and on rescan, all transactions come up as same date and time?

**Tags:** bitcoin-core

> **Comments:**
> **username_1**: The transaction data in the blockchain doesn't have timestamps, but the client knows when it sent a transaction so that is what normally will be added to the transaction. Since the client is learning of these transactions from the blockchain, perhaps the block timestamp should be used instead of the time the rescan occurs.  
> **username_0**: Ah, thanks. Yeah I'm surprised it doesn't use the block timestamp in the case of rescanning. Oh well... version 0.9 ?!  
> **username_2**: @username_1 post it as an answer!  
> **username_3**: Shouldn't this be considered a bug? I can see a very valid case for opening a request for change to the Qt client!  

---

## 1 answers

### Answer by username_4 on 2013-12-21. Score: 2

I've also had the same issue whereby importing a private key using RPC Console *importprivkey* will rescan and **tag it with the time which the rescan takes place** in btc-qt.

Even Multibit which uses the following format for private key (\*.key) files is only dated such that **the date corresponds to what is assumed to be the key's creation date**:
Kwnononok7xQwSNIPSNIPSNIPSNIPssthcheckth1s 2013-09-18T09:42:28Z

As mentioned, the Blockchain is not being consulted for transaction history - a major flaw IMO.

> **Comments:**
> **username_5**: I just ran into this again _today_!  

---

