Cryptographic algorithms are not time-aware, so you require a time-aware third-party to accomplish this. The third-party also needs access to a secure time source (like an on-site atomic clock or a secure connection to an offshore one)
The precise implementation and protocol depends on your usecase, but as an example you could have a server that does two things:
- accepts inputs that include a message to timelock and a "release date"
- allows requests to obtain the message only once the message's release date is passed
For the first case, the server would generate a random symmetric key of sufficient length, encrypt the message with it, hash the encrypted message and add the key + the hash + the release date in some database. The server then returns the hash that serves as an identifier for the message that was just timelocked. It can also return the encrypted message, if needed (presumably, the entity submitting the message destroys his plaintext copy after as he is the one wishing to timelock it).
Then, in the second case, the client sends the identifier to the server. The server looks it up, and checks the release date. If it isn't passed yet, the server denies and bails, however if it is, the server simply returns the correct encryption key (and the plaintext message if desired).
That's just one example of a very basic timelock service (you can elaborate by using public-key crypto to enhance various aspects of the service, for instance).
Your question is quite broad, perhaps you should add more detail.