I like the Module Setting Idea w/a default to the Site TZ...But, would the setting be per Event?  Given your example, some events will be fixed, while others would be converted...this will , no doubt create confusion w/users, unless their is some to let them know in the UI...suggestions?

As for DST, this is a pain...we need to modify the DNN TimeZone.XML table to add:

1) DST Start and End Date/Time (2 new fields)
2) DST Offset
3) Create a Form to Adjust the DST/TimeZone table (not all locales observe DST...and unfortunately the politicians seem to change it...case in point this year's Microsoft issues)

A couple of methods that will given a date/time convert to/from TZs using the upgraded TimeZone.XML file...

Finally a recommendation...store all date/times in UTC Offset +0...this will be uneffected by Locale DST/TimeZone changes.

Thanks Sebastian.  I think I understand.  I would think the way to operate w/TimeZones would be to display all Dates/Times in the User's TimeZonee (unless Anonymous).  However, w/the DNN Core, not all users realize they can set/change their timezone...  This may be something we want to add to the Skin Objects and allow users to see and/or change...in other words put it more in their face in the UI.

I was thinking about a reorg of the TimeZone file to allow not only for Countries, but also Locales.  The might allow for Admins or specified Roles to Add/Change the TimeZone info, including DST settings or the locale.  I di read and look at the Mike Brumm class.  Also, now .NET 3.0 includes a TimeZone class (http://msdn2.microsoft.com/en-us/library/system.timezone.aspx).  I not one of Mike's recommendations was to store all internal dates/times in UTC offset +0 and convert when displayed.  This might cause some issues, but would eliminate the need for changing data further on down the line (like Microsoft's DST patch earlier this year).  When Microsoft put out their DST patch earlier this year, admins had to run an Exchange DB Update program in order to change all internal dates/times...this was because they store the Date/Time in non-UTC +0 format.  The only way to avoid this is to store in UTC +0.   All DNN modules would then need to convert (using the internal, perpetual TZ offset table) to the User's local offset when displaying...this is a tough thing to implement...but may be the only way to address the issue...