I\'m currently storing all times in UTC, to make things easier for when I start bringing multiple sites and servers online.
The problem comes in when translating
The problem with relying on the client to self-report their time zone is that there is always a chance (how big of a chance is debateable) that what you will really get is a UTC offset. If you get a UTC offset, your logic will work fine most of the time, but in reality will only apply to the exact timestamps produced by the client. Any past or future times may have a different UTC offset, and that can't be predicted without a proper time zone database. Near the daylight savings boundary, using UTC offsets can produce catastrophically wrong results.
Even besides that, some non-literate users (i.e. grandma) may not know how to set the time zone of their local system; or users on tunnelled sessions or virtual machines may have a "local" time zone that is not set for their actual preference.
Guessing the political time zone of the client based on what you know about that client (IP, etc) can be wrong, and can be quite annoying if there is no way for the user to override the guess. But for anonymous users or new user sign-up I see nothing wrong with using such a method as an initial guess, as long as you give the user some way to change it if it's wrong.
My recommendation would be specifically:
In implementing a web-based application previously that needed to display timestamps in localized times, I found that not all clients translate UTC to local times correctly for past and future dates. I had to perform all conversions on the server side. This may necessitate a web service that takes a local time and an Olson time zone and returns a UTC time.