That is a good observation and probably a great way to auto-set a user's TZ setting but it only fixes half the "problem" some of the time. On a regular website (where you're not voting via POST constantly like here, most BB sites seem to take votes via GET) then you only get the post on login which happens maybe 1x daily or 1x 2 years.

Next is visitors who don't ever register. They never POST so the TZ will always be undetermined by the server but it will almost certainly be known by the client's machine; hence the need for client side something like JavaScript.

I'm not saying there's a wrong or right way to solve this, just trying to demonstrate what different users will see. Singapore users might get the right time, and whatever slice of Indonesia, etc is in the same TZ, but the other 23 TZs in the world will see datetimes out of sync with their own time. You just have to decide if this is important or not in your situation.

This is one I've considered for a site I'm working on and I will sheepishly admit that while I favor a client-side JS solution converting server side UTCs, I have yet to do the legwork to share the function() to do it. Maybe I've embarrassed myself into doing it today. :)

update: fixed bad paren, missing word, apostrophe.

update 2: well, I gave it a shot: Perl + JavaScript to display "correct" local times for datetimes. I'll give it a couple weeks of thought before I start using it in live stuff but I think I like it. Thanks for unintentionally prodding me to finally work on it.

This is a very good point. I used this site to see what the two browsers I have installed send back (Netscape 7.2 and IE 6.0, both on Win2K). Neither sends a Date header for a GET. In addition, my O'Reilly HTTP: The Definitive Gude says that sent dates may not contain time zones and may not be GMT. So I'd have to vote for a JS method. The only other intriguing idea, just for the pure geekiness of it, is to take the IP address from the HTTP header and do a look up at one of these IP geographic location sites.