Eric,

Thanks for the heads up.

Our recent changes related to DST have been an effort to get around an issue in .NET itself. When a .NET application starts up, the .NET automatically caches the time zone information as of that moment. Unfortunately, .NET doesn't automatically update this information when a DST or other time zone change occurs, so we implemented a workaround by having SmarterMail clear the time zone cache every hour. Unfortunately, it looks like there are some .NET time-related data types that use their own cache for time zone data which is not cleared when the main time zone cache is cleared.

We will take another look at this to identify what is still holding onto the time zone information.

Andrew,

Like I said not a huge deal, reboot worked, just wanted to wait a bit until EST work hours ended before I took action. If scheduling a reboot twice a year at 2am or a bit after, isn't the end of the world...

Andrew, would this be fixed if SM relied on DateTime.UtcNow and simply adjusted the datetime offset as needed, or does the caching issue still come into play?

Unfortunately, the caching issue still applies.

We are currently using DateTime.UtcNow extensively throughout SmarterMail. The problem is that .NET caches the time zone definitions the first time an app does anything with a time zone - including calling DateTime.UtcNow.  Attempts to retrieve the datetime offset after the cache has been initialized only retrieves the cached data.

In addition to the change we made previously to clear that cache every hour, we have also identified a few classes that use their own time zone caches. The latest version now clears the cache every hour for those classes which support doing so, and we have removed our dependence on classes that are unable to clear their cached time zone data.