Comment 6 for bug 389544

A low-risk fix has been commited for the client in stable/5.0, just to avoid tracebacking when the server timezone is not recognized (web-client already handled this gracefully). The fallback method when it fails (i.e. when the user has a TZ set in the preferences, but the server-advertised TZ is not recognized) is to consider that the client is located in the server's TZ.
(rev: <email address hidden>)

As for the proper fix in trunk, here's what I plan to do:
- To avoid all sorts of risky migration operations, we won't attempt to explicitly store all timestamps in UTC, which would be a valid solution to the general timezone issue
- Storing the timestamps in the server's TZ also has the interesting property of allowing easy import/export of time data directly from the database in an intuitive timezone
- To limit the timezone detection headaches, we will try a basic identification, but provide mechanism to set the timezone manually by providing a server-side config option (TZ env variable and explicit config option). We will also keep using time.tzname when it contains a valid value, and finally default to UTC if all else fails (with a warning).
This should be reasonably backwards compatible while providing a flexible way of correcting the server's timezone.
- On the client side, we need to unify the time offset calculation, which is currently split all over the place