My vote is for UTC with a caveat.
I supported an application that used UTC to store all date values and then had a ton of logic converting to and from time zones inside the database. I ran a trace and did some stats against the number of function calls. Over 80% of the calls in the database were just converting time zones. (actually, close to 90%)
This logic should have been at the presentation layer, but it was placed inside the database instead. The complaints by the customer base about performance issues were not too terribly surprising.
Fixing this after the fact proved to be a daunting challenge, one that I believe remains to be met.
One other question that comes to mind is the display of times prior to the alteration of the DST start and end. Do we code logic to check for the old and new settings? (for some of us the database layer and the presentation layer are our concern)
How about this date/time:
2006-03-23 15:00:00.000 (in local time zone)
This is prior to the change in 2007, but it would be rather complicated to perform DST logic that accounted for the old and new setting.
Most conversion logic would actually make that into:
Why? That date falls in the current start and end dates for DST values after 2007. Should programmers have to write code updates when the administration-de-jour decides changing this will have a positive impact?
One more reason to hate DST...
Hmmm, I have a good QOD related to UTC now. Steve, want to reconsider your rule about no time questions... :o)