8

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?

RLH
  • 2,162
  • 5
  • 24
  • 35
  • 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 Feb 20 '13 at 12:44
  • 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 Feb 20 '13 at 12:45

3 Answers3

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
micjamking
  • 191
  • 1
  • 4
  • But that timestamp being off by hours isn't really *useful* right? – Pacerier May 24 '14 at 23:01
  • 1
    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 May 25 '14 at 01:43
5

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.

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.

Nick ODell
  • 29,184
  • 11
  • 69
  • 129
  • 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 May 24 '14 at 22:56
  • @Pacerier I'm unsure what you mean. I just said that transactions don't have a timestamp. – Nick ODell Oct 16 '14 at 21:07
4

Transactions do not have a time per se. They do have a lock_time which is currently not used anyway.

Blocks do have timestamps, bytes 69-72 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.

cdecker
  • 9,319
  • 1
  • 38
  • 61
  • 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 Feb 19 '13 at 20:39
  • 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. – Stephen Gornick Feb 20 '13 at 12:42
  • @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 May 24 '14 at 23:00
  • 1
    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 May 24 '14 at 23:53
  • @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 Apr 17 '18 at 12:02
  • 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 Apr 17 '18 at 13:30