user97854: Let's say we have transaction X and transaction Y. The timestamp of X is chronologically earlier than that of Y. X's spender broadcasts X to the network and the same goes for Y's spender.
Let's say that miners receive Y first and they add it to the next block, which reaches the max number of stored transactions. Will X be included to the block after this one? Will it be discarded?
If X will be included to the block after this one, isn't it a problem that it happened before Y?
Thanks in advance for your answers!

user127631: A transaction itself doesn't have a storage structure for timestamp. So the transactions don't know when they're created. But, after bundling the transactions into a block and while solving the hash problem to solve the block, the miner inserts timestamp at the block level.
So, even if in reality chronologically earlier transaction comes later, it will be included into the next block if current block if full. Low fee transactions mostly experience this.
Imagine Alice is paying Bob
Alice puts a timelock on the transaction,

Time locks are a transaction level encumbrance. That is, the transaction is invalid and not propagated if it did not age past it's locktime.
But know that the UTXO the locktime transaction is spending(referencing) is free to be used. So, while Alice shows Bob that the transaction is under timelock, Alice can meanwhile spend the referenced UTXO and make that timelocked transaction invalid after it becomes ready to be propagated(past timelock) and Bob is scammed one could say.

Bob asks Alice to use CheckLockTimeVerify,

CLTV is a UTXO level encumbrance. So the transaction from Alice will go through as valid and a UTXO is added to Bob's UTXO set. That UTXO is spendable only after the time specified in UTXO has elapsed.
So if Bob wants to spend that UTXO, he has to create a transaction referencing that UTXO and have timelock value greater than or equal to CLTV value on UTXO.

This way, Alice has paid(sent UTXO) to Bob and Bob can be sure that he isn't going to get an invalid transaction.

97854: <p>Let's say we have transaction X and transaction Y. The timestamp of X is chronologically earlier than that of Y. X's spender broadcasts X to the network and the same goes for Y's spender.</p>

<p>Let's say that miners receive Y first and they add it to the next block, which reaches the max number of stored transactions. Will X be included to the block after this one? Will it be discarded?</p>

<p>If X will be included to the block after this one, isn't it a problem that it happened before Y?</p>

<p>Thanks in advance for your answers!</p>
 127631: <p>A transaction itself doesn't have a storage structure for timestamp. So the transactions don't know when they're created. But, after bundling the transactions into a block and while solving the hash problem to solve the block, the miner inserts timestamp at the <strong>block level</strong>.</p>
<p>So, even if in reality chronologically earlier transaction comes later, it will be included into the next block if current block if full. <strong>Low fee transactions mostly experience this</strong>.</p>
<p><strong>Imagine Alice is paying Bob</strong></p>
<p>Alice puts a <strong>timelock</strong> on the transaction,</p>
<ul>
<li>Time locks are a <strong>transaction level encumbrance</strong>. That is, the transaction is invalid and not propagated if it did not age past it's locktime.</li>
<li>But know that the UTXO the locktime transaction is spending(referencing) is free to be used. So, while Alice shows Bob that the transaction is under <strong>timelock</strong>, Alice can meanwhile spend the referenced UTXO and make that timelocked transaction invalid after it becomes ready to be propagated(past timelock) and Bob is scammed one could say.</li>
</ul>
<p>Bob asks Alice to use <strong>CheckLockTimeVerify</strong>,</p>
<ul>
<li>CLTV is a <strong>UTXO level encumbrance</strong>. So the transaction from Alice will go through as valid and a UTXO is added to Bob's UTXO set. That UTXO is spendable only after the time specified in UTXO has elapsed.</li>
<li>So if Bob wants to spend that UTXO, he has to create a transaction referencing that UTXO <strong>and have timelock value greater than or equal to CLTV value on UTXO</strong>.</li>
</ul>
<p>This way, Alice has paid(sent UTXO) to Bob and Bob can be sure that he isn't going to get an invalid transaction.</p>
