Work days, index field for every granularity of time (for fiscal calendars that don't align to calendar granularities), day number of every time span, display fields stored in text ("I don't care about the intricacies of date formatting in locales, just make it always look like this "), abbreviations of display fields.
How about the retail requirement of capturing store open/close status for year on year comparisons? Date dimension becomes Store_Date dimension, with indicators for what to include/exclude in comparison totals?
I give trainings on dimensional modeling and query design/optimization. The vast majority of my examples are for dates, for two reasons.
1. Everyone needs some form of date dimension.
2. If you can solve date problems, you can apply any other logic you want trivially.
2 is not 100% true, but sometimes it seems that way.
