A. You could set up an remote email account and throw away the key.
Put a crazy password on gmail (or any email service that you expect to still be in business when the time comes). Get it to send you a cryptographic key or to send you the password at a time that is programmed in the future.
Then you throw away the gmail password. No 2 factor authentication, no way of getting back in. The problem is that you have to rely on gmail.
Future mail: gmail calendar, lettermelater...
If it's under your control, you can "hack" the time.
The problem with a windows or local solution is that you can change the time or fake an ntp server. Anything that reboots either has to be told the time or can be updated with new time info.
So somebody else would have to run the clock. Having and external service to send you a message at a certain time is the answer I believe. The important thing is being sure that that external service is reliable and redundant when the time comes so that you don't lose the info forever.
Redundant could mean having two or more files with the data, with two different passwords, on 2 different hard drives, with two different remote email services from 2 different companies.... Basically doing your setup twice in 2 completely independent ways with no single point of failure.
Encryption has to do with security, not time.
Your question refers to a password. You can use a cryptographic key simply to increase the complexity and make so that it is not accessible via simple brute-force. That's beyond the subject and a bit complicated but it might interest you.
You could encrypt your data with PGP encryption and send yourself the encryption key later. If security is a concern, using an encryption key rather than a long password would be preferable.
If you are using a password, then having 10 characters or more that are random and include symbols and caps would be a minimum, in my estimation. The more random characters in your password (the longer it is), the better as it makes it exponentially more difficult to brute-force.
Beyond that, the stackexchange page referenced by Sam3000 is worth mentioning.