The most commonly overlooked case of when not to use UTC is for scheduling of future times - especially in recurrence patterns.
Imagine if you're alarm clock was scheduled by UTC. Say you set it for 7:00 AM daily. On the day after a DST transition, you'd either wake up at 6:00 AM or 8:00 AM depending on which direction the transition was.
Also, the rules by which we determine time zone offsets and daylight saving time changes get updated all the time! So you can't take some future local time and convert it to UTC without also retaining the local time itself. Otherwise, when things change, you won't have an original source of truth and again all your times will be off.
I've posted on this many times before.
Of course, once the event has occurred, then you certainly want to record the time either at UTC, or using a DateTimeOffset.
Another common use case is for dates without times, especially birth dates and other anniversary dates. These should always just be stored as year, month, day (such as in a date
field type in most databases) - with no conversion between time zones or UTC.
Regarding your specific points:
If I decide to store the event times in UTC ... it will be difficult to display them...
That is quite easy actually. Almost every programming environment can do this easily. The only place this is difficult is in JavaScript for non-local time zones, and there are libraries to cope with that.
If I decide to store the event times in UTC ... it will be very difficult to query them (i.e. if I want to show all events that happened on 2014-01-15 local time I need for each event to compare that event's time with what '2014-01-15' means in that event's timezone. Not sure if this is even possible in SQL...)
That is true. Everybody's "today" is different. If you need data tied to a floating "day" then that is another case for not storing in UTC. However, a DateTimeOffset
would give you the advantages of both.
If I decide to store the event times as local times ... I will not be able to compare times of events for different locations (but this is ok for me)
It's more than that. A local DateTime without an Offset may be ambiguous to to daylight saving time fall-back transitions. So you could have a single local value that you can't distinguish which of two points in time it corresponds to.
Regarding "television time" - reserve that concept for things that are truly "floating". Example: A company has offices all over the world that all start at 8:00 AM. That's a floating time.