We are a government agency regulating energy resource development. We are "open" (we need to be able to be contacted) 24 hours a day. The time component of a transaction can be important in lag/duration calculations. e.g. time to respond to reported upset condition.
Since I'm new to dimensional modeling all I have to go by is the direction I've read in Ralph Kimball's book where he recommends separating the date and time dimensions.
A robust time dimension could have columns which define "breakfast time", "lunch time", "business hours", "morning", "evening", "night" etc. and would enable queries such as; what events occurred "in the morning", "over lunch", "during business hours", "after business hours", "evening", "night" etc.
Most of our systems capture dates as DATETIME. I can imagine scenarios where either us or a stakeholder, could make/save changes seconds apart at any time of the day/night.
It could be that I'm off base here and this is unrealistic in the real world...
I should also point out that, at present, it is VERY early days for our dimensional data warehouse and we don't presently have a specific requirement for time dimension. I presume that like a date dimension, it is one of those "bellybutton" conformed dimensions that every data warehouse should have. Is that wrong?