The logs are written using DateTime.Now for the server.

While I realize that is what it SHOULD be doing... it definitely is not.

Here is a shot from the Administrator logs when I just logged in as "superadmin".  Notice the discrepancy between Time Stamp in the logs and the time showing in in the lower right corner of the image directly from the server task bar.

If I run the diagnostic option, it DOES come up with the correct date/time.

This really looks like an issue in the code that is filling the Log files to me.

This is a server running Windows 2019 Standard.

The version of SmarterMail is shown in the image above.

Rod

Here is an enlarged version of that first image (well, I resnapped it so the time are a little off, but they definitely show the 2 hour discrepancy I am talking about).

Hello Rod, I took a quick look at this and believe this is definitely something we may want to look into. As such, I suggest submitting a support ticket so we can investigate further and get to the bottom of it. First though, have you tried applying any necessary Windows updates and updates to the .NET platform on the SM server? We've seen some misc issues resolved in customer environments by applying the latest .NET quality rollup, and this might be worth a shot as well. Let me know what you find out when you have a moment. Have a great rest of your week Rod. 

Hello Kyle,

Yes, I have the latest greatest Windows Updates installed on my 2019 server.

This morning I checked our SmarterMail Enterprise installation at my office on Windows 2016 and it DOES NOT have this issue.  Timestamps in those log records match up with the system time just fine.

So this is either a Windows 2019 Standard, a SmarterMail 100.0.7016, or a FREE VERSION of SmarterMail issue... or some combination of those items.

Also, poked around a bit more this morninig and
found the Service\Settings\Settings.json file, in there

    "time_zone_index": 20

No clue if that is correct or not for "Central Standard Time"
But it is the same as the setting on our Enterprise system at the office, so am assuming it is correct.

Wrote my own little .Net application that simply calls DateTime.Now.ToString installed it on the 2019 server and executed... it comes back with the PROPER time.  

This again, points to something amiss in the SM Service in interpreting local timezone.  The 2 hour difference is the confusing part as we are -6 currently from UTC so its like it has the WRONG timezone not just defaulting to the default zone.  

The one thing that DOES make sense is that the date/time stamps in the logs... would be MDT... which I believe is the SM home-base timezone isn't it?   Possibly some "test" setting during development that didn't get yanked before public release ?  

Rod

Rod, thanks for getting back to us on this. First, I'm working on setting up a 2019 Server machine right now and should be able to get this tested by end of day. I'll follow up here once I've had a chance to try reproducing the timezone issues you're having there. Next, I can confirm the 20 you're seeing in the settings.json file is expected, and correlates to CST as you suspected. In my environment this is configured for -1 (use system time.)  There aren't any additional timezone configurations I'm aware of at the system level, and this is all handled with the DateTime.Now operation as Robert pointed out earlier. I'll reach out to update you on my test results as soon as possible, but I definitely recommend submitting a support ticket on this so we can help you get to the bottom of it. Have a great day!

Rod, quick follow up for you on the 2019 testing. I set up a 2019 base server on AWS, configured for our local timezone, deployed SmarterMail and checked the logs. I've attached screenshots showing the comparison.

Correct, now change the timezone on the server to NOT be Mountain Time, set it to Central Standard Time.

I'm betting you still get logs stamped in Mountain time.   That is where I think the error exists.  It is NOT reading the local time zone, but rather it always defaulting to the AZ time zone (I think that is Mountain Time).   Which ... would explain the 2 hour difference.

I tested using Central Time on a local VPS, time is correct using the 7016 build.

Ok... NOW, we have a mystery.

Is your installation the "freebie" 10 account version ?

Rod

Yes, it is the free version. Though I dont see how the edition would affect the time being written. Note that if you change the timezone after running for a bit, log lines already written will have the time written for the timezone it was at that time, SM does not adjust the already written line's time offset for the new timezone.

I tested changing my timezone on the Server 2019 machine and the time was reflected properly before and after the change. I believe this is a server issue Rod, is there any chance you could use the link below to move a backup of these domains to a test server to see if the issue persists there? 

https://portal.smartertools.com/kb/a2724/migrate-smartermail-to-a-different-server.aspx 

The licensed version of SmarterMail does not affect the timezone usage/detection/printing. If you have not applied all available Windows/.NET updates I suggest doing so at your earliest convenience as we have seen some misc issues resolved in customer environments by applying the .NET roll up update that was recently released, and this may have a positive impact on your environment as well. 

Will be a little delayed trying this... (going to be out of town for a bit)... probably make an attempt next week (after 4/23).  Thanks for the info!  We'll get this sorted out.

Installed 7040 and restarted server, issue is resolved.  (was on 7016 prior).

Rod

Thats great news Rod, thanks for trying that out!