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
I wouldn't do ip geolocation. It can be very inaccurate, especially free services. Just ask the user for zip code or state, and store it in cookie.
You can, using javascript (which knows the local time), change the user-inputted time to UTC before sending the data to your server. Then, send UTC down in a format such that javascript can turn it from UTC into local time.
For example, a date to UTC to be sent to the server:
(new Date("November 11, 2011 23:13:42")).toUTCString()
And UTC to local time, for rendering:
(new Date("October 17, 1986 15:29:13 UTC")).toLocaleString()
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.
You can't reliably get a user's timezone from the request headers. That's why most website ask users to set their timezone in profile settings. However, you can use various tricks to try to get. One trick is to use Google's IP-to-location api to find out where the user is coming from and then try to guess the timezone from the geo location. This is not 100% reliable either, but will get you closer to the truth.
just realized this has already been asked here at least once: get user timezone
I've done it like this. You may need to easy_install pytz for timezone objects.
import pytz
import time
import datetime
d = time.time()
print datetime.datetime.fromtimestamp(d, pytz.timezone('US/Eastern'))
print datetime.datetime.fromtimestamp(d, pytz.timezone('US/Central'))
print datetime.datetime.fromtimestamp(d, pytz.timezone('US/Mountain'))
print datetime.datetime.fromtimestamp(d, pytz.timezone('US/Pacific'))
The d variable here is storing UTC time as a unix time stamp.