<p>If you are literally referring to the "time" or "blocktime" property of a transaction within the blockchain, then this timestamp is in Unix format.</p>

<p>And if by "convert it to a meaningful value", you mean a human-readable format, you can use a unix command line (e.g. Terminal on OSX) to do a quick conversion:</p>

<p><strong>Linux:</strong></p>

<pre><code>$ date -d @1395103695
</code></pre>

<p><strong>Mac OSX:</strong></p>

<pre><code>$ date -j -f "%s" 1395103695
</code></pre>

<p>...which would return the following:</p>

<pre><code>Mon Mar 17 14:48:15 HST 2014
</code></pre>

CC BY-SA 3.0
2014-05-24T23:01:49.853Z
But that timestamp being off by hours isn't really *useful* right?
Pacerier
CC BY-SA 3.0
2014-05-25T01:43:20.947Z
That's not _really_ OP's question, i.e. what format is the timestamp in within a transaction in the blockchain. I edited my answer because I'm inferring that what he meant by "meaningful" is "human-readable". 
The usefulness of this data is subjective.
micjamking
CC BY-SA 3.0
2014-03-18T01:33:38.740Z
2014-05-24T21:59:57.100Z
2014-05-24T21:59:57.100Z
micjamking
<p>Transactions do not have a time per se. They do have a <a href="https://en.bitcoin.it/wiki/Protocol_specification#tx" rel="nofollow">lock_time</a> which is currently not used anyway.</p>

<p>Blocks do have timestamps, <a href="https://en.bitcoin.it/wiki/Protocol_specification#block" rel="nofollow">bytes 69-72</a> after trimming the protocol headers and checksums. Some may say that a transactions time is the time of the block that included it.</p>

<p>Another interpretation (the one used by blockchain.info) is simply the first time the transaction was received by the peer.</p>

CC BY-SA 3.0
2013-02-19T20:39:21.577Z
I think that would work.  Actually, I have an idea for a project, but I need to know the time a transaction showed up in the chain (or was received by a peer, as you suggest.)  Is the time stamp on the peer unreliable?
RLH
CC BY-SA 3.0
2013-02-20T12:42:39.073Z
If you need something immutable not even the timestamp for the block is useful because a block reorg can still occur even once a transaction is in a block.
Stephen Gornick
CC BY-SA 3.0
2014-05-24T23:00:09.027Z
@StephenGornick, That's confusing, do you mind elaborating on it? Do you mean that the current timestamp for block 200k http://api.blockcypher.com/v1/btc/main/blocks/200000 which is 2012-09-22T10:45:59Z can be *modified* in the future?
Pacerier
CC BY-SA 3.0
2014-05-24T23:53:33.077Z
Only if a fork below block 200k is created and it overtakes the current chain. The timestamp in the block is immutable but the transaction may appear in another block with a different timestamp.
cdecker
CC BY-SA 3.0
2018-04-17T12:02:11.293Z
@cdecker Is it an arbitrary process which block transactions wind up in after a reorg, or would you expect it to be a block created roughly before or after the original block?
ryanjdillon
CC BY-SA 3.0
2018-04-17T13:30:05.833Z
The naturally occurring block forks do not have any coordination, so it is expected that each miner will just pick whatever suits their policy. So during a reorg this kind of time assignment may end up with arbitrary new timestamps.
cdecker
CC BY-SA 3.0
2013-02-19T20:37:07.183Z
2013-02-19T20:37:07.183Z
cdecker
<p>There are several things you could mean by the time of the transaction:</p>

<ol>
<li>When the transaction is created</li>
<li>When the transaction is known about by 90% of the network</li>
<li>When the transaction is first included into a block</li>
<li>When the block is known to 90% of the network</li>
</ol>

<p>We can't know 1, because it could have been generated offline, and there's no time field. You can assume that 1 is 30 seconds or so before 2, but again, you can't know.</p>

<p>We can figure out 2, because the time that we receive the transaction is going to be pretty much the same as when 90% of the network does. For historical data, <a href="http://blockchain.info/api/blockchain_api" rel="nofollow noreferrer">blockchain.info has an API.</a></p>

<p>We can figure out 3, because there's a time field in the block. However, that can be off by up to an hour, and the network won't care. Still, there's not much reason to lie about it.</p>

<p>Figuring out 4 is pretty much the same as 2.</p>

CC BY-SA 3.0
2014-05-24T22:56:16.567Z
Regarding point 2 and point 4, blockchain.info doesn't record the time when they received the broadcast right? (meaning they only record the timestamp of the transaction created, which can be off by hours)
Pacerier
CC BY-SA 3.0
2014-10-16T21:07:52.537Z
@Pacerier I'm unsure what you mean. I just said that transactions don't have a timestamp.
Nick ODell
CC BY-SA 3.0
2013-02-20T05:06:23.147Z
2017-01-19T20:41:48.690Z
2017-01-19T20:41:48.690Z
Nick ODell
<p>This may be a very simple question to answer, but I haven't been able to quickly find it.  Regardless, if you were to deconstruct a transaction in the blockchain, and pull out the time value of the transaction, what format is the time stamp in?</p>

<p>In other words, if you were to pull out the draw time value, how can I convert it to a meaningful value?</p>

CC BY-SA 3.0
2013-02-20T12:44:58.077Z
Does the time need to be known right away, or just historical data (i.e., not including transactions from the most recent six blocks).  Also, what granularity.  Does knowing the block's timestamp solve the problem or do you need real-time as they arrive?  Either way, these values are not immutable -- is that a requirement?
Stephen Gornick
CC BY-SA 3.0
2013-02-20T12:45:48.653Z
Well, what I'd like to do is monitor the time difference between received transactions for a specific address.  In other words, I'd like to see how often transactions are sent to a specific address.  The data needs to be specific to the network, not necessarily the time the user posted the payment within their client.
RLH
<transactions><blockchain><timestamp>
What format is the time of a Bitcoin transaction stored in?
RLH
# What format is the time of a Bitcoin transaction stored in?

(Asked by: username_0 on 2013-02-19)

This may be a very simple question to answer, but I haven't been able to quickly find it. Regardless, if you were to deconstruct a transaction in the blockchain, and pull out the time value of the transaction, what format is the time stamp in?

In other words, if you were to pull out the draw time value, how can I convert it to a meaningful value?

**Tags:** transactions, blockchain, timestamp

> **Comments:**
> **username_1**: Does the time need to be known right away, or just historical data (i.e., not including transactions from the most recent six blocks).  Also, what granularity.  Does knowing the block's timestamp solve the problem or do you need real-time as they arrive?  Either way, these values are not immutable -- is that a requirement?  
> **username_0**: Well, what I'd like to do is monitor the time difference between received transactions for a specific address.  In other words, I'd like to see how often transactions are sent to a specific address.  The data needs to be specific to the network, not necessarily the time the user posted the payment within their client.  

---

## 3 answers

### Answer by username_6 on 2013-02-20. Score: 5 | Accepted answer

There are several things you could mean by the time of the transaction:

1. When the transaction is created
2. When the transaction is known about by 90% of the network
3. When the transaction is first included into a block
4. When the block is known to 90% of the network

We can't know 1, because it could have been generated offline, and there's no time field. You can assume that 1 is 30 seconds or so before 2, but again, you can't know.

We can figure out 2, because the time that we receive the transaction is going to be pretty much the same as when 90% of the network does. For historical data, [blockchain.info has an API.](http://blockchain.info/api/blockchain_api)

We can figure out 3, because there's a time field in the block. However, that can be off by up to an hour, and the network won't care. Still, there's not much reason to lie about it.

Figuring out 4 is pretty much the same as 2.

> **Comments:**
> **username_3**: Regarding point 2 and point 4, blockchain.info doesn't record the time when they received the broadcast right? (meaning they only record the timestamp of the transaction created, which can be off by hours)  
> **username_6**: @username_3 I'm unsure what you mean. I just said that transactions don't have a timestamp.  

---

### Answer by username_2 on 2014-03-18. Score: 9

If you are literally referring to the "time" or "blocktime" property of a transaction within the blockchain, then this timestamp is in Unix format.

And if by "convert it to a meaningful value", you mean a human-readable format, you can use a unix command line (e.g. Terminal on OSX) to do a quick conversion:

**Linux:**

```
$ date -d @1395103695

```

**Mac OSX:**

```
$ date -j -f "%s" 1395103695

```

...which would return the following:

```
Mon Mar 17 14:48:15 HST 2014

```

> **Comments:**
> **username_3**: But that timestamp being off by hours isn't really *useful* right?  
> **username_2**: That's not _really_ OP's question, i.e. what format is the timestamp in within a transaction in the blockchain. I edited my answer because I'm inferring that what he meant by "meaningful" is "human-readable".  The usefulness of this data is subjective.  

---

### Answer by username_4 on 2013-02-19. Score: 4

Transactions do not have a time per se. They do have a [lock\_time](https://en.bitcoin.it/wiki/Protocol_specification#tx) which is currently not used anyway.

Blocks do have timestamps, [bytes 69-72](https://en.bitcoin.it/wiki/Protocol_specification#block) after trimming the protocol headers and checksums. Some may say that a transactions time is the time of the block that included it.

Another interpretation (the one used by blockchain.info) is simply the first time the transaction was received by the peer.

> **Comments:**
> **username_0**: I think that would work.  Actually, I have an idea for a project, but I need to know the time a transaction showed up in the chain (or was received by a peer, as you suggest.)  Is the time stamp on the peer unreliable?  
> **username_1**: If you need something immutable not even the timestamp for the block is useful because a block reorg can still occur even once a transaction is in a block.  
> **username_3**: @username_1, That's confusing, do you mind elaborating on it? Do you mean that the current timestamp for block 200k http://api.blockcypher.com/v1/btc/main/blocks/200000 which is 2012-09-22T10:45:59Z can be *modified* in the future?  
> **username_4**: Only if a fork below block 200k is created and it overtakes the current chain. The timestamp in the block is immutable but the transaction may appear in another block with a different timestamp.  
> **username_5**: @username_4 Is it an arbitrary process which block transactions wind up in after a reorg, or would you expect it to be a block created roughly before or after the original block?  
> **username_4**: The naturally occurring block forks do not have any coordination, so it is expected that each miner will just pick whatever suits their policy. So during a reorg this kind of time assignment may end up with arbitrary new timestamps.  

---

