You cannot do this with the current framework, and the TimeZone API is
really poor. You cannot enumerate available timezones, you cannot even
create a timezone with a given offset. All you can do is read the machine's
timezone, as it has been configured through the control panel, and convert
DateTime to UTC and back to the local timezone.
This is really insufficient. I have posted a request to enhance the timezone
API on the Whidbey beta newsgroup, asking specifically for the following
features:
* Enumerating timezones
* Associating a timezone to the current thread, the same way you can
associate a culture to the current thread, which is exactly what you suggest
(of course you can define your own ThreadStatic variable, but it won't have
any influence on the way DateTimes are formatted and parsed, so it is of
very little help, we need a framework level variable that works like
CultureInfo.CurrentCulture).
I would really like to see this feature in the next version of the
framework, but I feel that it won't make it unless more people complain
about the weakness of the current API (usually the .NET API is richer than
the Java API, but here is is much weaker). So, if you feel that the TimeZone
API is too weak, and if you want this feature in the next version of the
Framework, raise your voice.
Bruno.