Bitcoin blocks real date: time vs median time

[mavenlog]

Hi all,
I'm compiling some statistics about the arrival time and I was surprised to find that the timestamp included in block n+1 can sometimes be earlier than that of the preceding block n.

The wiki in https://en.bitcoin.it/wiki/Block_timestamp says it's ok:

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.
Whenever a node connects to another node, it gets a UTC timestamp from it, and stores its offset from node-local UTC. The network-adjusted time is then the node-local UTC plus the median offset from all connected nodes. Network time is never adjusted more than 70 minutes from local system time, however.

So we have 2 times in a block: the miner timestamp, and the median time.
I want to classify these blocks by date, but depending on whether I choose the timestamp or the median time, the dates can be different (see below)

Height   Timestamp                   Median time 
17898   23/06/2009 23:19:42    23/06/2009 20:34:45
17899   23/06/2009 23:32:39    23/06/2009 21:05:33
17900   24/06/2009 00:12:58    23/06/2009 21:40:41 <--
17901   24/06/2009 00:35:19    23/06/2009 22:25:33 <--
17902   24/06/2009 01:04:59    23/06/2009 22:57:21 <--

My question is: which one would you choose?
If say you wanted to count the number of blocks on the 23rd, would you go with the timestamp or the median time?

[1714947781]

1714947781

[1714947781]

1714947781

[ranochigo]

From my understanding, they aren't that much different. The median time as given by Bitcoin Core is simply a timestamp from 6 blocks prior (including the block in question). This means that by looking at the median time, you are just looking at a timestamp of the previous block, which can still be subjected to the inaccuracies of the timestamp system. The median time in a block is only useful if you're looking for a timestamp that is strictly increasing.

I would probably just go with the timestamp, the accuracy for either isn't different.

[pooya87]

I want to classify these blocks by date, but depending on whether I choose the timestamp or the median time, the dates can be different (see below)

It depends on your purpose for this classification. The two values represent different things. One is from the block itself and the other is from other blocks.
Timestamp is the time that the clock of the system running the node that constructed the block was showing. Or in other words the time that is stored in the blockchain.
Median time is the time calculated using the previous blocks.

[mavenlog]

Thanks for the answers.
The goal of this classification is to see how many blocks arrive on any given day on average.
I know it's a block every 10 minutes but sometimes more, sometimes less.

The timestamp is closer to reality, the median time gives a time of about an hour prior.
My problem really is because sometimes a block would give a time that is in the next calendar day, and a subsequent block would give a time that is in the day prior...
So a few consecutive blocks can have dates like so: 23/06-23/06-24/06-23/06...

I'm leaning towards using the timestamp as it's closer to reality, although I find it annoying that some blocks will end up being counted towards another day because miners are setting the time too far in advance.

[pooya87]

The goal of this classification is to see how many blocks arrive on any given day on average.

The timestamp is the more accurate way to go.

because miners are setting the time too far in advance.

Since each computer has its own clock and there is no central authority to dictate that time, sometimes differences like this happen. That is why the whole median time and the 2 hour allowed gap were used.

[mavenlog]

Makes perfect sense, thank you very much!

[odolvlobo]

The goal of this classification is to see how many blocks arrive on any given day on average.

I think that an accurate count of blocks in a day is not possible because the timestamp is not accurate (and is not intended to be accurate). There may be ways to improve the accuracy, but in the end there is no way to know definitively which day should be assigned to any blocks mined around midnight.

However, you wrote "on average", so just using the timestamp may be good enough.

because miners are setting the time too far in advance.

Since each computer has its own clock and there is no central authority to dictate that time, sometimes differences like this happen. That is why the whole median time and the 2 hour allowed gap were used.

I believe that the main reason for the inaccuracy is the use of the timestamp to vary the hash, and not the differences between clocks.

[n0nce]

I guess you could run your own node and just check when your node received a block.

Even though per protocol, sometimes a later block (height) can have an earlier timestamp, this issue is removed if you just check on your machine at the end of the day how many blocks it has.

Of course this only works from whenever you start your program (like, today), not for past blocks.