One consideration not brought out in the other answers is the difference between what is available and what is prominent. Your settings interface should expose the options that are most important to most of your users, which you will identify through user testing, review of comparable sites, analytics (seeing what people actually do post-release), or other means. You should be reviewing both which settings to expose and how many to expose, the latter to avoid "analysis paralysis".
However, you may have more-specialized options that a smaller number of users will care about, but they'll care enough to really want them. Some places you'll find these "in the wild": the "advanced" button in a configuration interface, Firefox's about:config settings, and those extra controls on your digital camera that fine-tune light levels, white balance, etc. In all of these cases the default behaavior is reasonable for most users, but those requiring extra control -- because they're advanced, because they have accessibility needs, or just because they're very particular for some other reason -- are available.
How much of this should you do? That really depends on your research and your context. For an application that people will be "living in" (like an operating system), you'll probably end up with more. For a web site that users will spend 15 minutes on, anything beyond basic settings is probably overkill, so be governed by your use cases.
One last thought: there is no value to settings that users don't know are there. If you have an interface, make sure it is discoverable. This might mean always-present (persistent gear icon, for example) or contextually-dependent (YouTube's player controls that appear when you mouse over a video that's playing). I'm having trouble thinking of a case where only time-based is a good idea, particularly for a web site where someone might have chosen "open in new tab" and won't even look for some time yet.