Should future time be stored in UTC or local time?
In general I agree with your appraisal. When a time is going to be used under any of the following circumstances using local time only is appropriate:


There is some other bit of context that makes the time zone obvious or irrelevant.


The time is going to only be used in reference to a local event like a concert. Since I know the concert is taking place in venue X it would be weird if the time wasn't in the time zone for venue X. Similarly it would be weird if my doctor's appointment was made based on a different time zone than the location of the appointment.
I shouldn't have to set a time zone to get the alarm on my phone to go off at 6 o'clock in the morning. I should be able to say 6 am, and the phone should wake me up everyday at 6 am local time. Note I'm just talking about a basic alarm like you would have with a clock radio. I'm not talking about scheduling a meeting/appointment with people in different time zones.

For some reason the fact that X occurs on a regular interval is more important that X occurs at a specific time.


Something needs to happen once a day and it doesn't really matter when it happens. Usually you would like to do some scheduled task during non-peak hours, but it is conceivable that this isn't always important.



Assuming the above is true then I'd fully support using local time. You didn't mention the database platform, but if your database platform supports it I think an event that isn't tied to a date should be stored in a pure time data type, assuming your database platform supports/offers this data type. For instance in SQL Server, I'd use the Time data type to store the hours of operation for a store. Using SQL Server once again, I'd use the DateTime2 data type to store the date and start time for a concert.



Since we're on the subject I personally would use UTC time on the server for everything that doesn't fit in the "local time only" parameters I outlined above, like you stated in your question. Many database platforms offer an analog to SQL Server's DateTimeOffset but this isn't really a safe solution because you end up losing the actual time zone information in lieu of the offset, and offsets change. For a more detailed overview on this and other time related issues, from a .NET point of view, check out this article written by Jon Skeet.