Site time zone, portal time zone, same thing. Say you upgrade from 2.1.2 to 3.2.2, then immediately install the AVCalendar. At that point your server and site (portal) time zones haven't been set. If you upgrade your DNN, know that there's a new setting called portal time zone, set it, then upgrade your AVCalendar doing the change during installation would work. My point is a mass change should be there after the upgrade process. I did it no problem with a SQL call, but people without SQL access (or knowledge of what fields to set) wouldn't be able to do that. It doesn't need to be fancy, just possible.
I think the handling of timezoneoffset should be cleaner. I should be able to change the time zone of an event to anything I want. It should be stored in GMT+0, and have these capabilities with the addition of a "displayoffset" column.
a) If "displayoffset" is not set, the authenticated user should see time displayed in their user time zone, unauthenticated users see it in portal time zone. In both cases the event native time zone should be displayed on details.
b) If "displayoffset" is set, then all users should see time displayed as the local time for the event, no matter what their login state, but the local time zone again should be visible in the details. This would in some cases mimick the was the calendar was before, no times ever changed by user, but with the added benefit of the user know what time zone the event was being held in.
c) Recurring events should follow a) and b), but display the time / date for the date selected, not the origin date. For example if I have a yearly event recurring every 52 weeks, if I'm looking at January 2007 on the calendar and click the details for the event it should say "January 29th, 2007", not "January 31st, 2005" when the event was for set-up.
I wouldn't necessarily look at Outlook as a shining example. First off, it has the option of displaying multiple time zones. I'll also have to note that I've missed a flight because of Outlook's time zone handling (or lack of it). If you have a flight that leaves Dallas at 12:30 Central, and arrives Greensboro at 4:30 Eastern, displaying that at local time doesn't work for either.
In any case I look at it this way. If I want to put up a regional event calendar in say, Indiana where there are multiple time zones, I'd need the ability to enter events in multiple time zones and have the calendar know which time zone each of them were in. A user wouldn't want to have keep changing their personal profile to determine when events started where they were being held, particularly if they had to travel to get there and they may be viewing events from multiple time zones in a single session. They just need to know that it starts at 8:30 am Eastern. However, if they're attending something like a conference call they want it shown in their local time. In essense, users need to know what time it will be when they are participating.
I'll give you an example about how NOT to handle it. Active.com handles event calendars and registration for the entire country. All times on it's database are Pacific time, but not really. Since it doesn't deal with timezones at all you have to put your event start times in local time (i.e. 8:00 am, instead of 5:00 am Pacific). That was the person showing up knows they have to be there at 8:00 am. However, you even up putting your cutoff times in pacific time (and they're displayed that way) because to cut off registration at 12:00 midnight eastern you need to enter 9:00 pacific. The user sees cut-off is 9 pm, when it's really midnight.