I took this from Andreas' book "Mastering Bitcoin" (2nd edition, page 158ff):

To lock it to a time, say 3 months from now, the transaction would be a P2SH trans‐ action with a redeem script like this:

[now + 3 months] CHECKLOCKTIMEVERIFY DROP 
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG

where is a block height or time value estimated 3 months from the time the transaction is mined: current block height + 12,960 (blocks) or current Unix epoch time + 7,760,000 (seconds).

The problem is that we are currently at ~506000 blocks, so if this should be a block height, and not a time range, it must be ~94000 blocks in the future.

CLTV and nLocktime use the same format to describe timelocks, either a block height or the time elapsed in seconds since Unix epoch. Critically, when used together, the format of nLocktime must match that of CLTV in the inputs—they must both reference either block height or time in seconds.

If nLocktime is nonzero and below 500 million, it is interpreted as a block height, meaning the transaction is not valid and is not relayed or included in the blockchain prior to the specified block height.

So in your case it must be:

94000 CHECKLOCKTIMEVERIFY DROP 
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG

You could achieve the delay also with nLocktime, then the tx is not put into the blockchain before the block appears (I think the tx stays in mempool), but with the CLTV it goes directly into the blockchain (is visible in the blockchain), and can only be retrieved after block height is reached.