<blockquote>
  <p>1) Are these valid transactions?</p>
</blockquote>

<p>Yes</p>

<blockquote>
  <p>2) If they are valid, how can I assign a valid timestamp to these
  transactions? Would it be 'fair' to simply assign them the block's
  timestamp? </p>
</blockquote>

<p>You can do anything. Yesterday I've timestamped them as 1905, today as 2048</p>

<blockquote>
  <p>3) From what I understand about the Received Time, it represents the
  time that bc.info sees the transaction, so how can this this timestamp
  be occurring? Is it a bug?</p>
</blockquote>

<p>Yes.</p>

CC BY-SA 3.0
2015-06-04T17:45:57.870Z
Why are you allowed to timestamp them far into the past/future?
mrp
CC BY-SA 3.0
2015-06-04T21:03:08.333Z
Transactions do not have timestamp fileld! This is only bc.i point of view
amaclin
CC BY-SA 3.0
2015-12-02T08:23:55.890Z
@mrp Who would stop you and how would they stop you? You can put any timestamp on any transaction you want. My understanding is that blockchain.info claims to timestamp them based on when they first saw them, but it seems they sometimes screw that up.
David Schwartz
CC BY-SA 3.0
2015-06-04T05:26:19.410Z
2015-06-04T05:26:19.410Z
amaclin
<p>Block and transaction timestamps are unreliable in a peer to peer environment. See similar question here <a href="https://bitcointalk.org/index.php?topic=1164293.0" rel="nofollow">https://bitcointalk.org/index.php?topic=1164293.0</a> </p>

<p>You could have timestamp of block n > timestamp of block n+1. bc.info seems to reporting received time same as block timestamp, which seems to be a bug. I suggest you explore other blockchain apis like blocktrail and tradeblock .</p>

CC BY-SA 3.0
2015-12-01T07:37:27.247Z
There's no such thing as a transaction time stamp anyway so the point is fairly moot.
Claris
CC BY-SA 3.0
2015-12-01T05:41:07.673Z
2015-12-01T05:41:07.673Z
dark knight
<p>There seem to be some irregularities with Blockchain.info's transaction timestamp (aka <code>Received Time</code>) for a set of blocks.  The transaction times are recorded with unix timestamps well into the future (2017, 2022, 2035, etc..)</p>

<p>For example, here is a <a href="https://blockchain.info/tx/d2c39af85861f8cc1ee236919335f30f190ab2a9fcccf7bcaa9597432d7aa616" rel="nofollow">transaction</a> in block 237173 with a timestamp of 2035-05-27 00:00:59.</p>

<p>All the blocks that have transactions with a future <code>Received Time</code> are as follows:</p>

<p>237173
237175
237180
237181
237182
237183
237184
237185
237186
237187
237188
237189
237190
237191
237192
237193
237194
237195
237196
237200
237201
237202
237210
237280
237945
237980
238008
238013
238038
238227
239127
240078
241223
260657
260819</p>

<p>1) Are these valid transactions?</p>

<p>2) If they are valid, how can I assign a valid timestamp to these transactions?  Would it be 'fair' to simply assign them the block's timestamp? </p>

<p>3) From what I understand about the <code>Received Time</code>, it represents the time that bc.info sees the transaction, so how can this this timestamp be occurring?  Is it a bug? </p>

CC BY-SA 3.0
2015-06-04T00:07:46.067Z
A similar (answered) question is available here: http://bitcoin.stackexchange.com/questions/37721/bc-info-transactions-with-no-timestamp
Christopher Gurnee
CC BY-SA 3.0
2015-06-04T00:21:26.140Z
That's also my question, but I don't believe it's the same issue.  That answer is saying bc.info missed the transaction so it couldn't timestamp it.  Here there is a timestamp. Some are close into the future (Aug 2015) and some are very distant into the future (Apr 2078).
mrp
CC BY-SA 3.0
2015-06-04T00:28:20.873Z
Oops, I should have noticed that was your question. Since bc.i's backend is closed source, it seems unlikely (IMO) that you'll get a better answer to this question other than what you already know... that bc.i is a bit buggy....
Christopher Gurnee
CC BY-SA 3.0
2015-06-04T00:40:41.433Z
Np, it just seems like a really odd bug.  Anyway, I at least hope the info above could be useful to others.
mrp
CC BY-SA 3.0
2015-11-30T01:01:23.900Z
1) They are valid if they are in the best blockchain. 2) Take the timestamp from the actual Bitcoin block (instead of the Blockchain.info web service). 3) No idea, it's probably an idiosyncrasy of Blokchain.info's operations.
Nayuki
<transactions><blockchain.info><timestamp>
blockchain.info transaction timestamps set into the future
mrp
# blockchain.info transaction timestamps set into the future

(Asked by: username_0 on 2015-06-04)

There seem to be some irregularities with Blockchain.info's transaction timestamp (aka `Received Time`) for a set of blocks. The transaction times are recorded with unix timestamps well into the future (2017, 2022, 2035, etc..)

For example, here is a [transaction](https://blockchain.info/tx/d2c39af85861f8cc1ee236919335f30f190ab2a9fcccf7bcaa9597432d7aa616) in block 237173 with a timestamp of 2035-05-27 00:00:59.

All the blocks that have transactions with a future `Received Time` are as follows:

237173
237175
237180
237181
237182
237183
237184
237185
237186
237187
237188
237189
237190
237191
237192
237193
237194
237195
237196
237200
237201
237202
237210
237280
237945
237980
238008
238013
238038
238227
239127
240078
241223
260657
260819

1) Are these valid transactions?

2) If they are valid, how can I assign a valid timestamp to these transactions? Would it be 'fair' to simply assign them the block's timestamp?

3) From what I understand about the `Received Time`, it represents the time that bc.info sees the transaction, so how can this this timestamp be occurring? Is it a bug?

**Tags:** transactions, blockchain.info, timestamp

> **Comments:**
> **username_1**: A similar (answered) question is available here: http://bitcoin.stackexchange.com/questions/37721/bc-info-transactions-with-no-timestamp  
> **username_0**: That's also my question, but I don't believe it's the same issue.  That answer is saying bc.info missed the transaction so it couldn't timestamp it.  Here there is a timestamp. Some are close into the future (Aug 2015) and some are very distant into the future (Apr 2078).  
> **username_1**: Oops, I should have noticed that was your question. Since bc.i's backend is closed source, it seems unlikely (IMO) that you'll get a better answer to this question other than what you already know... that bc.i is a bit buggy....  
> **username_0**: Np, it just seems like a really odd bug.  Anyway, I at least hope the info above could be useful to others.  
> **username_2**: 1) They are valid if they are in the best blockchain. 2) Take the timestamp from the actual Bitcoin block (instead of the Blockchain.info web service). 3) No idea, it's probably an idiosyncrasy of Blokchain.info's operations.  

---

## 2 answers

### Answer by username_3 on 2015-06-04. Score: 0 | Accepted answer

> 1) Are these valid transactions?

Yes

> 2) If they are valid, how can I assign a valid timestamp to these
> transactions? Would it be 'fair' to simply assign them the block's
> timestamp?

You can do anything. Yesterday I've timestamped them as 1905, today as 2048

> 3) From what I understand about the Received Time, it represents the
> time that bc.info sees the transaction, so how can this this timestamp
> be occurring? Is it a bug?

Yes.

> **Comments:**
> **username_0**: Why are you allowed to timestamp them far into the past/future?  
> **username_3**: Transactions do not have timestamp fileld! This is only bc.i point of view  
> **username_4**: @username_0 Who would stop you and how would they stop you? You can put any timestamp on any transaction you want. My understanding is that blockchain.info claims to timestamp them based on when they first saw them, but it seems they sometimes screw that up.  

---

### Answer by username_5 on 2015-12-01. Score: 0

Block and transaction timestamps are unreliable in a peer to peer environment. See similar question here <https://bitcointalk.org/index.php?topic=1164293.0>

You could have timestamp of block n > timestamp of block n+1. bc.info seems to reporting received time same as block timestamp, which seems to be a bug. I suggest you explore other blockchain apis like blocktrail and tradeblock .

> **Comments:**
> **username_6**: There's no such thing as a transaction time stamp anyway so the point is fairly moot.  

---

