Timezone hassels in .Net - Daylight savings and change between UTC, GMT and others

At least with .Net 1.1 it is suprisingly tricky to perform data entry in a timezone other than in machine time ("local time"), or in UTC (Universal Time = GMT - to which daylight saving is never applied).

It is interesting to read the comment below on gotdotnet about why Microsoft do not support this, even though it seems they clearly do that already internally for the regional settings on the control panel and all the data is there in the registry. For me to calculate CET (Central European Time) I cannot just add one hour to Universal Time because daylight saving needs to be considered. PS: According to Wikipedia it is Daylight Saving not Savings.

Now I'm looking at a CodeProject class that obtains the information from the Windows registry. Trouble is, that if the calculation is ever wrong, there will be the possibility of a press release for a major company going live an hour out, using Microsoft Content Mangement Server (MCMS). I got an email from them where they accept this risk.


Here's the GotDotNet quote:

Does the .NET Framework support Time Zone conversions to any given Time Zone?

Not in V1.0, V1.1 or the Whidbey pre-release.The .NET Framework does support conversion to and from UTC and the systems current local time. It can also support parsing a DateTime from an arbitrary time zone offset, such as 2003-10-26T13:11:07+10:00, but it must always convert this either to Local or UTC.This is a very common feature request and is likely to be in a future version. People are often surprised why this feature cannot be supplied by Microsoft at low cost. In particular, data to do conversions exists in the Windows registry and is used by the time zone selection dialog. However, there is a big distinction between having UI and registry data and having an API.This is a more expensive feature to undertake for Microsoft than most people would imagine because (a) an API must provide consistent behavior from one machine to another so we cant just re-expose the registry data and (b) there is cost for Microsoft in exposing an official Time Zone conversion because we face on-going geo-political costs for any country/region based data we gather and maintain. For example, a country may threaten to boycott our product if they are not listed in the data. This has happened to us with our CultureInfo data on many occasions, and we often need to tweak data in service packs, which is expensive and risky.That being said, there is agreement that this is a very important feature, and it is under serious consideration for the WinFx release.

source:

http://www.gotdotnet.com/team/clr/bcl/techarticles/techarticles/DateTimeFAQ/FAQ.aspx

I still had a problem where the calculation was not symmetrical and I was losing an hour. The Gotcha that hit me is that parsing dates in or out from text one needs to set Invariant culture

DateTime.Parse("d", DateTimeFormatInfo.InvariantInfo());

Compiler Error Message: CS1595 - LoadControl() issue when debug set to false

A Google on this error returns two possibilities on microsoft.com (at time of writing). Neither documented solution applied here. However I remembered recently setting the web.config debug=false instead of true, which had triggered the error. I didn't have time to fully look into the problem, but it complained about a user control having two definitions, which really was true! The was being loaded dynamically with LoadControl() but there was still a static reference. I haven't thought through why it would have worked ok in debug mode. Anyone know? Perhaps the added debug hooks mask the error.

There could also be a bug somewhere in Visual Studio because the offending line was in the user control which in turn contained a script tag (client-side) with a src attribute. When the src attribute is commented out then the dynamic load of the user control caused no problems. In my case I can refactor this particular dynamic load out of the code anyway. Perhaps this points someone else similarly stuck in the right direction.