Storing all your time as UTC can create problems depending on what you're doing with the time. If your application is a calendaring application and people can book things well into the future, you can have problems with daylight saving time and timezones this way.
For my most recent app, timestamps are UTC and everything else is stored local time.
You'll need to store the time zone along with the local time, otherwise you won't be able to handle the situation where you have multiple users in different time zones. About the only reason this is preferable to storing UTC along with time zone, is because there are sometimes political decisions made to change daylight savings time (i.e. the mere fact of DST/TZs etc. isn't enough).
Yes, I store the timezone (associated with the user) along with the local time. All date operations in the application are done related to their timezone.
Storing it this way is preferable because it makes working with times across DST boundaries a non-existent problem. DST is a pain in the ass and you want to use whatever language / database facilities to exist to make this as smooth as possible -- storing local time (and setting the timezone appropriately) makes it not your problem. Also users frequently set their own timezone incorrectly, and when they fix their timezone, they don't want all their appointments to be at the wrong time.
A calendar application is a bit different, since the whole subject of the application is time, time zones, etc. Still I'd store all in UTC along with the user's time zone (you'd have to store the time zone anyway with localized time too).
Storing local time is preferable because it makes working with times across DST boundaries a non-existent problem and because users frequently set their own timezone incorrectly.
I've done previous projects where I've stored UTC dates or unix timestamps for this situation and it was a hassle to deal with. You really need to consider the nature of the data -- for straight forward timestamps (like the date of a post) UTC makes the most sense. For user-entered dates, I think local time is much more appropriate and a lot simpler.
Don't you get exactly the same problem when you store timezones? CET always stays == UTC + 1 hour. So there's no difference whether you store 8 CET or 7 UTC, because some country may decide it's not in CET at that time anymore... Only storing the actual location would save you if you're thinking about dates in far future.
Then again, you'd have to somehow verify what's the time in that location at that point.
I don't store timezone offsets, I store the timezone strings and they are pretty granular. Users can choose the most appropriate timezone from 448 possibilities.
For my most recent app, timestamps are UTC and everything else is stored local time.