I'm not sure if this issue should be opened here but I noticed the problem downstream on both on bdk-cli and bdk-jni.
If you sync the wallet while an incoming transaction you did not initiate (not a self-transfer) is in the mempool, the timestamp given to the transaction in the database will be 0. Note that this behaviour (putting a timestamp of 0 if transaction is seen but still in mempool) is not consistent across transactions, because if the transaction is a send (coming from the wallet) it will add the timestamp as time broadcast, whereas if it's a receive, it will put the timestamp at 0.
An example of the problems this causes is that one would have to keep track of time of transactions separately instead of using the bdk timestamp, otherwise you run into situations like these (note the Jan 1, 1970 timestamp):
I think it makes sense that the true timestamp of a transaction be the time at which the block containing that transaction is mined (not when the transaction was broadcast). In that sense the 0 is not bad, but in any case the most important part is that it should be consistent across receive/send transaction types.
Another small problem we have right now is that because the transaction data is not updated once the transaction is added to the cache/db, a transaction seen first when it was in the mempool will forever keep a timestamp of 0, even after more syncs of the wallet once the transaction has been mined. The only solution at the moment is to delete the wallet and recover (mobile) or delete the cache and recover (cli).
I'm not sure if this issue should be opened here but I noticed the problem downstream on both on
bdk-cliandbdk-jni.If you sync the wallet while an incoming transaction you did not initiate (not a self-transfer) is in the mempool, the timestamp given to the transaction in the database will be 0. Note that this behaviour (putting a timestamp of 0 if transaction is seen but still in mempool) is not consistent across transactions, because if the transaction is a send (coming from the wallet) it will add the timestamp as time broadcast, whereas if it's a receive, it will put the timestamp at 0.
An example of the problems this causes is that one would have to keep track of time of transactions separately instead of using the bdk timestamp, otherwise you run into situations like these (note the Jan 1, 1970 timestamp):
I think it makes sense that the true timestamp of a transaction be the time at which the block containing that transaction is mined (not when the transaction was broadcast). In that sense the 0 is not bad, but in any case the most important part is that it should be consistent across receive/send transaction types.
Another small problem we have right now is that because the transaction data is not updated once the transaction is added to the cache/db, a transaction seen first when it was in the mempool will forever keep a timestamp of 0, even after more syncs of the wallet once the transaction has been mined. The only solution at the moment is to delete the wallet and recover (mobile) or delete the cache and recover (cli).