Timelock is an umbrella term for four different mechanisms: transaction-level nLockTime, script-level OP_CHECKLOCKTIMEVERIFY (CLTV/BIP65), relative nSequence locks (BIP68), and OP_CHECKSEQUENCEVERIFY (CSV/BIP112). Time-based checks use BIP113 Median Time Past.
Bitcoin has two absolute and two relative lock mechanisms. nLockTime constrains a whole transaction; CLTV constrains a script branch against that nLockTime; BIP68 gives inputs relative age; CSV lets Script require that relative age.
nLockTime is a 32-bit transaction field. Zero means no absolute lock. If every input has nSequence = 0xffffffff, an otherwise unsatisfied nLockTime is ignored, so at least one non-final sequence is needed for the lock to matter.
Values below LOCKTIME_THRESHOLD = 500,000,000 are block heights; values at or above it are Unix timestamps. The threshold changes the interpretation of the same field rather than defining a protocol date.
Time-based locktime is evaluated against the previous block's Median Time Past, not a candidate block's freely chosen timestamp. Bitcoin Core uses GetMedianTimePast when checking finality for the next block.
OP_CHECKLOCKTIMEVERIFY from BIP65 requires the spending transaction's nLockTime to meet an absolute height or time and requires a non-final sequence on that input. CLTV does not wake up or broadcast anything by itself.
For version-2-or-higher transactions, BIP68 interprets nSequence as a relative delay from the spent UTXO's age, in blocks or 512-second units. A disable flag can turn relative-lock semantics off for an input.
OP_CHECKSEQUENCEVERIFY from BIP112 lets a script branch demand a minimum relative age. CSV is useful when a recovery or penalty path should become spendable only after a delay, including Lightning constructions.
SEQUENCE_FINAL = 0xffffffff can neutralize transaction nLockTime when used by every input. BIP68's disable flag is a separate bit with separate semantics; CSV treats an operand carrying that flag as a NOP for forward compatibility.
Reaching the height or time only changes validity. A wallet still has to retain or construct the transaction, satisfy signatures and other Script conditions, pay a sufficient fee, propagate it, and obtain confirmation.
Inspect nLockTime, transaction version and each input's nSequence, then inspect the locking script for CLTV or CSV. decoderawtransaction exposes fields and testmempoolaccept shows whether a candidate is currently acceptable.
For the clearest picture, read this entry together with CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, Lightning Network, Payment Channel, Transaction, Bitcoin Script. The reverse links also lead from Confirmation, Bitcoin Script, HTLC, CHECKLOCKTIMEVERIFY.