I sometimes ask an interview question: can you think of any situations in which it's not appropriate to store a date and/or time as UTC? Most eggheads, includ

I sometimes ask an interview question: can you think of any situations in which it's not appropriate to store a date and/or time as UTC? Most eggheads, including many senior engineers, will think for a bit and eventually say no. It's beyond dogma at this point that storing localtime is bad mmmkay. The one exception I've encountered (I suppose there could be others) is when the value is to be used for recurring event scheduling and you need it to happen at a certain time locally. For example, this event should fire at 1am Central Time every other Tuesday morning. Since "Central Time" obeys Daylight Savings, the time component of the UTC representation of "1am" will lose and gain back an hour as the months of the year go by. So instead you would store "1am Central Time" as the scheduled time and fire the job whenever it's currently 1am Central Time. ** If I've overlooked a way to accomplish this with UTC, I'm all ears. I suppose you could have a job that predicts upcoming event fire times and stores them as UTC. For example, "next fire time" could be generated right after the event fires, as the UTC representation of 1am Central Time two Tuesdays from now.