Functionality that depends on a certain period of time elapsing or on a specific future date has always been a bane to functionality testers. In previous projects I've seen the standard hack of modifying the local machine's system time but this can create other problems with other components such as the web server or database. So the question remains: how does one best perform future date functionality verification?
An elegant and customizable solution is to hold this information in a table, and always refer to that table when performing any date comparison logic. If the table has a particular flag to use the system date then the application will grab this date. If the flag is to use a date in the table (a custom date) then this date will be used. All date comparison would then be performed by a single class that handles the appropriate logic around checking the database, getting the correct date, and returning it to the particular method that is using the date. Of course, the standard necessity of using this consistently remains.
Using a table to store a configurable date for the purposes of future date validation is a nice way to overcome the hassles and hacks of modifying local system times. The primary question (and perhaps challenge) is how to implement it in an existing system and to use it across the application consistently so that you are sure your app is stable and returning expected results.