How to sync Sucuri timezone to Server timezone

This is probably related with this other ticket [1].

Most of the information displayed by the plugin in its pages is done through the WordPress function “date_i18n” [2] which supposedly takes the information set by the administrator in the general settings page for the GMT offset [3] and time format, but somehow it keeps reporting the wrong date and/or time. For the information listed in the “Audit Logs” panel we use EDT and then convert it to local time using that WordPress function once again.

I will ask my co-workers to see if they have another idea of how we can fix this issue. Can you take a screenshot similar to the one provided by the person who started the other thread? That will help me to compare the information and get more test cases.

[1] https://www.ads-software.com/support/topic/last-login-time-mismatch-from-version-1710
[2] https://codex.www.ads-software.com/Function_Reference/date_i18n
[3] https://en.support.wordpress.com/settings/general-settings/2/#timezone

Thanks again for the quick and awesome response @yorman.

Here is a screen shot.

Hello @yorman, just following-up on status.

I will ask my co-workers to see if they have another idea of how we can fix this issue.

Have they come up with a solution yet?

Not yet, and I did not have much time last week to check this on my own because I was working in other internal projects. Today we released a new version of the plugin which includes a few bug fixes but none of them was intended to address this issue with the inconsistency of the datetimes.

I will take some minutes (now) to talk with the maintainer of the API service that powers the audit logs, any modification in the plugin must be considered a breaking change against the API so I can not modify anything without his approval. I will update this thread when I have more information.

thanks

See https://www.ads-software.com/support/topic/where-are-sucuri-time-zone-settings?replies=7#post-7256106

Thanks @ViktorSzépe. I read through and I did not see an obvious solution to implement.

Shouldn’t Sucuri correct this problem in their code?

@yorman

I will take some minutes (now) to talk with the maintainer of the API service that powers the audit logs, any modification in the plugin must be considered a breaking change against the API so I can not modify anything without his approval.

How did that conversation go?

The solution is very simple: do not call datetime().

The solution is very simple: do not call datetime().

Right. But keep in mind I am not doing anything – I’m merely pointing out an issue. Your suggested solution needs to be taken into consideration by @yorman and his development team so they can correct the [minor] issue.

Yes, I will fix the issue, I just have to find a way to unit-tests this modification through multiple timezones. Most of my co-workers are not very familiar with the code that powers the plugin (they work in different projects) so their suggestions only work if I disconnect the code from the WordPress methods. I will add that option that I promised and we can consider other solutions from there.

I removed the GMT addition here [1] and it seemed to work in my tests. regarding the new option that I promised to add, I decided that it was not a good idea after all, people may get more confused with two different options to configure the timezone than by the incorrect times. Lets test this new code and see how it goes.

[1] https://plugins.trac.www.ads-software.com/changeset/1215017

Thanks @yorman…once the Sucuri plugin updates on my server I’ll test it and report back.

Hello @yorman. Just checking in to see if the bug is still on the radar screen with you.

Good morning @yorman. Any plans to roll-out the datetime stamp fix in the Sucuri plugin?

I just updated to v6.0.16. I see there was attention paid to the width of the logo:
Fix: Added width to logo in activity report email.

Any attention being paid to the inaccuracy of the reported date?