Why not just use the blockchain to determine date? Since the tx is broadcast with no confirmations as soon as it gets 1 confirmation you know the date was based on the block prior to that confirmation.
Because they don't know which block it will end up in, and if they waited until 1 confirmation it would no longer be an instant payout (which is the real attraction here, along with knowing the "proof is in the blockchain" as far as being able to verify that there is no cheating).
The thing is, the player doesn't care which secret is used, they just want to verify that the secret that was supposed to be used when the wager was placed is the exact same one that truly was used in determining the result.
So currently the criteria that determines which secret to use is simply the date that the service first sees the transaction. The reason that there is a new secret every day is that the secret is revealed only after one full day after the deadline has passed (e.g., the secret for wagers processed on the 10th of the month is kept secret until the end of the 11th of the month, and then revealed at the start of the 12th of the month.
There are two other variables that could help. The address that the wager is being sent to, and the amount. That's it though.
So one approach would be to have a different wager address for every day. That's not very good for usability. Even limiting that, like toggling between two addresses day-to-day, might be something to help with this situation, bit it wouldn't be ideal.
The other approach would be accommodate an optional signal indicating which secret is to be used by encoding that into the wager amount. Take a list of secrets numbered sequentually, there is odd and even numbers. Adding a Satoshi to the wager amount (e.g., a 0.1 wager would be 0.10000001) would require that when determining the result the closest odd-numbered secret must be used. Then the a 0.10000002 wager would require that the closest even-numbered secret is used.
Neither of these is useful to the person playing by manually doing a copy and paste of the wager address -- you don't want them to be thinking of time of day, etc. But I foresee the day there is an iPad app, for example, acting as a gaming terminal with a local wallet. This device provides a dead-simple user interface to the game. The logic in that app would automatically handle whatever is necessary to eliminate the risk where it is ambiguous as to which secret should be used. And I suppose, of the methods above, having a different address for each secret would be the most correct approach. Since it is a piece of code determining which address to use it really doesn't matter that it changes day-to-day then.
So, there's the solution.
Keep the existing list of addresses which are used when doing manual betting. Those wagering manually extend trust that the service is not cheating on the end-of-day wagers. Then for the the automated systems a set of addresses that are associated with each secret are created ahead of time. If there are any wagers sent after the address expires then those wagers get returned. Since the addresses are known well in advance, the device could start using the following day's address an hour or so earlier just to ensure to not get too close to the expiration to prevent submitting any bets that would get returned.
This issue regarding being able to specify which secret a bet is against probably isn't necessary to address right away. A player can avoid the risk by simply not betting near when the time switch occurs. But the site should consider making an API that will allow an automated gaming termine to send a calendar date + bet choice (e.g., under 48,000) request. The response will be the return the hash of the secret that will be used for that day as well as the bitcoin address for that specific wager (e.g., for the under 48,000 bet) on that day.
