I'm not sure I understand your solution.

Are you suggesting that we need to keep track of when events were added and then modify this TimeZoneOffset in order to spoof the control into thinking it's the correct time? Or do we just need to keep track of when DST has occurred?

You comment of "All you should need to do, is set the TimeZoneOffset to what it was before the DST was applied" sounds to me like next time the DST changes I will need to go back into my code and change this TimeZoneOffset back to what it was before? This doesn't sound like a very practical solution.

Do I just need to keep track of the current status of DST and then adjust the TimeZoneOffset accondingly?
Here some example code of how I am attempting to solve this problem, although it seems like something that should be part of the control already.
Any feedback on this would be helpful.

if (DateTime.Now.IsDaylightSavingTime())
  myWebScheduleInfo.TimeZoneOffset = new TimeSpan(Properties.Settings.Default.LocalTimeZone, 0, 0);
else
  myWebScheduleInfo.TimeZoneOffset = new TimeSpan(Properties.Settings.Default.LocalTimeZone - 1, 0, 0);

We did solve the DST problem for our particular application.  I'm not using PreRender, I am using ActivityUpdating, ActivityAdding, and WebScheduleInfo_DataBind to adjust the UTC saved or local time displayed based on TimeZoneInfo.GetUTCOffset(d).

for details check out this blog post I just put up at

http://dotnetjunkdrawer.blogspot.com/2010/02/infragistics-webschedule-and-daylight.html

I hope it helps, and if you can see any improvements let me know!

I have solved the DST problem.  I am preparing a blog post about it :)

I'm trying to get DST working, has anyone made this pre-render solution work?

Problem I am seeing is, when I create an appointment from the web month view and the popup dialog, the web month view does not appear to be firing the pre-render event again when finished so the appointment is displayed without eing adjusted.

The following is a modification of 1stconsulting's post. It compares the current DST with the appointment's DST.

            //Determine Timezone of passed date

            TimeZone localTimeZone = TimeZone.CurrentTimeZone;

            DaylightTime passedDaylight = localTimeZone.GetDaylightChanges(EventStart.Year);

            if (EventStart >= passedDaylight.Start && EventStart <= passedDaylight.End)

            {

                PassedEventStartIsDST = true;

            }

            //Determine Timezone of now

            DaylightTime dlt = localTimeZone.GetDaylightChanges(DateTime.Now.Year);

            if (DateTime.Now >= dlt.Start && DateTime.Now <= dlt.End)

            {

                IsDST = true;

            }

            //Adjust the time to match daylight savings if now is not in DST but the appointment is (or the reverse)

            if (PassedEventStartIsDST != IsDST)

            {

                if (PassedEventStartIsDST)

                {

                    EventStart = EventStart.Add(dlt.Delta);

                    EventEnd = EventEnd.Add(dlt.Delta);

                }

                else

                {

                    EventStart = EventStart.Subtract(dlt.Delta);

                    EventEnd = EventEnd.Subtract(dlt.Delta);

                }

            }

I'm a bit confused by the apparent solution. Are there not two separate, but related issues: the standard time zone offset, which is fixed; and the separate six-monthly effect of daylight saving time?

 The main issue which applying the standard offset does not seem to resolve is viewing appointments in one daylight saving zone when the user is now in a different daylight saving period - which is not the same as being in a different timezone. Timezones are fixed offsets. Daylight saving periods are not.

 I have two appointments, both saved in UTC, both with a standard timezone offset applied.

 The first is for 26 April, at 09:00 UTC. This appointment was entered after daylight saving time began. This appointment correctly displays as at 10:00 local time(using a dayview with a standard offset applied)

 The second is for 26 March, also at 09:00 UTC. This appointment was entered before daylight saving time began. .This appointments also *incorrectly * displays as being at 10:00 (using a dayview with the same standard offset applied) – although the appointment would have been correctly displayed if viewed on the date it was made.

 The change to daylight saving time, a one hour difference,  happened between these two dates.

If I use a dayview control today, with a standard timezone offset applied, to view those two appointments, they appear to be on different times: the appointment on 26 March should appear to the user to be at 09:00, not 10:00

 Stephen - I think the issue is not applying a standard offset - which should happen - but the problem of viewing across daylight savings boundaries, which vlsystems raised. I've also submitted tickets to Infragistics on this point, but I have never received a working solution to this problem. The only reply I've received relates to the standard timezone offset part - which is not the point. Are you able to suggest any practical solution to daylight saving period cross-boundary viewing?