There are problems which involves time locking a secret from being distributed until a certain time later.
One way is to set an encryption that can be broken in a consistant rate of time. However time taken to break it is based on CPU speed, not actual time or date.
This system on the other hand,
rely instead on a decryption key being split into multiple parts (so that it becomes a shared key).
A packet is then sent to each timeserver at random, with this structure.
Figure 1 (packet to each timeServers):
[ (a) Parts of the shared key and it's hash, (b) trigger date and/or daemon event, (c) bitcoin payment to not release it early]
Figure 2 (packet to each payloadServer):
[ (a) hash manifest- list of hash of other keys , (b) bitcoin payment to perform it's duty, (c) encrypted Payload]
After the timeserver receives the packet in fig1, that server will then wait for a trigger event, like a date. When triggered, that timeserver will then announces the hashfile of the shared key it is holding to all payloadServers in the world.
The payloadServer holding the packet in fig2, performs the job of trying to match the hash manifest with all the declared hashes of shared keys. On a full match, the payloadServer will grab all the keys from each listener and then decrypt and execute the payload's data and instructions. The payload will most of the time be a textfile, and the hash of the file that would be sent to a public repository or other payloadServer to display to the public. Alternatively the decrypted file could be a virtual machine daemon executing simple events like sending an email to a person; to complex events, such as ordering an assassination, or controlling a swarm of deathbots over IP.
--------
P.s. Crypto signed commands could perhaps be sent to timeservers to extend release time (with appropriate bitcoin compensation), or cancel releases.
P.s.s Timeservers are more effective if behind an anonymising network like tor or i2p
P.s.s. Timeservers conditional triggers could perhaps even be an algorithm for more complex trigger. Doesn't have to be purely time based.
P.s.s.s Why not have a single server release the key after a certain time? Well what if that server gets bribed to release it early? Having shared keys reduces the risk of betrayal. However if a timeserver gets shutdown early, it may be wise to allow each server two or three parts of the shared keys as redundancy.
P.s.s.s.s Bitcoin is ultimately optional, but helps motivate the server to stay honest, and to keep the servers running.
Idea is inspired by a novel called Daemon by Daniel Suarez
----------
Tl;DR: Network of servers collectively only releasing decryption keys after a trigger event like a date.