3
Daylight savings time change still having issues. Build 8097
Problem reported by Eric Tykwinski - 3/14/2022 at 7:14 AM
Resolved
Just a heads up...  Apparently the fix didn't work for us on the Daylight Savings time change.
I'm going to assume a reboot will fix the issue like last time, but wanted to let people know.

Running the latest build.    
SmarterMail Enterprise   
Build 8097 (Mar 3, 2022)

Here's the headers from a MAPI account to an IMAP account.
Received: ; Mon, 14 Mar 2022 10:07:37 -0500
From: "Eric Tykwinski" <user@truenet.com>
To: "user2@truenet.com" <user2@truenet.com>
Subject: Test DST
Date: Mon, 14 Mar 2022 10:07:37 -0400
reply-to: user@truenet.com
Message-ID: <7064adcb164548b8812832a8f41f81ff@truenet.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary=f13ae17218014e8ca8fb2cd53f574540
X-SmarterMail-TotalSpamWeight: 0 (Authenticated)


5 Replies

Reply to Thread
3
Andrew Barker Replied
Employee Post
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 Barker Software Developer SmarterTools Inc. www.smartertools.com
0
Eric Tykwinski Replied
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...
1
Employee Replied
Employee Post Marked As Resolution
This has been addressed in today's release of Build 8125:
Fixed: An occasional issue where the received header shows the wrong time zone after a Daylight Savings change.

0
echoDreamz Replied
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?
3
Andrew Barker Replied
Employee Post
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.
Andrew Barker Software Developer SmarterTools Inc. www.smartertools.com

Reply to Thread