And hope you did not forget any or change the computer clock before you run the test to make sure?... if it's a timebomb within production code, no thanks.

Extra thanks for my part. The sort of fuzziness on deadlines is no small part of why things slip. I find real deadlines tremendously important in life and one of the easiest ways to tell apart people I want in my life and people I don't. I died a little inside every time someone at university begged, cajoled, or threatened a professor into extending a deadline. Sidenote: Come to think of it, maybe checking a server clock should be a part of any robust deployment and test suite.

Being realistic, of course you're right, schedules slip. I think there are at least three ways to approach it.

1. Don't use the "die" argument. If you're in the kind of company that lets millions of error log lines stack up with warnings without caring, what's another 100,000?
2. Use named environment constants -- like MILESTONE_3_a => '2008-08-02' -- to set the dates so they may be updated at a single point as the project might require.
3. Use the callback sub ref to allow deprecated code to still run while in the production environment only.

For the interface it might be nice to be able to have confess, cluck along with die and warn as args... or hooks for your local exception mechanism...?

I think the "timebomb" thing is a bad idea at all. It should *warn* that at some time in the future it won't be available, it can even have a prediction of when that is, but I don't think it makes any sense for a software to have a different API depending on the Date.

I would suggest, however, to replace the Dates for using version numbers, saying that the method is deprecated since version X, and is expected to be removed by version Y, but no automatic disabling of the method.