Time zones and Localisation
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:

Include the Olson time zone as part of any user profile.  The time zones can be looked up by country, and this should make user selection of their time zone relatively painless.  Give the 0.01% of users who care the choice of straight-up UTC also :-)
If you populate the default in the user profile with an IP-based guess, you'll be right most of the time if you use a good lookup service.  But allow the user to change it if it's wrong.
For anonymous users, provide some kind of widget on any page that displays or inputs local times, that lets them select their Olson time zone, in much the same way as for a user profile.  Store the value they choose in a cookie.  Default to UTC or to a guessed value as above.

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.
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 date and datetime objects into strings in my templates and when accepting user input. 6:00PM UTC doesn't mean a whole lot to someone who is  in PST. Likewise, asking users to input times in UTC is asking for disaster. 
How can I correctly translate these values in a smart, not-error-prone way? Is there a way I can determine from the HTTP request what timezone a user is in? I really need a way to determine the user's timezone with as little effort as possible.