Felenasoft

This is an old problem that just seems to be skipped, so I thought I would post some old data and reaffirm against the newest version of Xeoma.
Server OS: Debian 9.4 with NTP client running and a stratus 2 source
Timezone on server: UTC-6 no daylight savings (we are daylight savings free)
Xeoma Version: 18.6.14
License: Commercial (not pro)
Brief:
Xeoma has had an issue with emailing timestamps for as long as I have used it (2016). Simply put the emailer within Xeoma has a bug that causes the emails to be marked 12 hours ago. This is a problem I have tracked down before and can reaffirm that is still exists. The problem stems from the way Xeoma uses the local time and UTC time, for the archive it uses UTC and the timezone info from the server, for emails it uses local time and the timezone data again to create the email timestamps.
Changing the Xeoma client user timezone has no effect of the email timestamps that the server sets. This setting is for archive display only.

What appears to be happening is the emailer is using the calculated Xeoma time that Xeoma uses for the archive or the local time from the system and again applying the local systems timezone data to have the affect of the emails being sent at a different time even though I can see when the emails are being processed through my email server. In my case UTC -6 for my local time and emails are 12 hrs behind local time. eg. it is 1759 local, UTC is 2359, Xeoma sends an email with a timestamp of 0559.
I have tracked this down to a simple point of programming that needs to be redressed: have the emailer use either the local time or utc plus/minus the timezone of the system, not a mix of both. There should be no time calculations required for sending an email from within Xeoma.

The Hack to fix this:
Set your servers local tzdata to UTC (GMT if you want daylight savings). Now Xeoma sends emails with the correct timestamp. Your archive will have the correct time if you set your client user time zone to your local timezone.

Comments:
Servers should be set to UTC and have the correct timezone for proper logging and file timestamps, the above method means all system local times are in UTC and not local. if using a remote log server, the time stamps will also be in UTC causing the log to show various times in the logging order. A timestamp cleanup process that adjusts the log timestamp to local time before writing to the log may be required.
All around this flaw is annoying and creates issues that just should not be there.

Hello! Have you tried selecting the exact time zone of your server in Main menu -> Remote access -> Users ? This means not only the marker (e.g. GMT-02:00) but the actual name of the time zone too (e.g. Asia/Beirut and Asia/Jerusalem are not the same, even though the markers coincide).

Yes,

It does not matter which setting is chosen, the behavior is the same when the email module sends an email.

I think I have the exact root of the problem, if the servers tzdata is set to local and the hardware clock is set to utc and Xeoma is set to any time zone, the timestamps of the emails xeoma sends will be out by the amount of the timezone that xeoma is set to plus the timezone that the server is set to. So for my example: we are utc-6 here. Our hardware clocks are set by ntp to utc and the OS sets the timezone for the system time for logs etc. Xeoma uses both the hardware clock and the system timezone for different parts. The hardware clock plus the offset in xeoma is used for the video archive while the email module uses the system time plus the offset.

I have duplicated this in various versions of xeoma on debian 7, 8, 9, ubuntu 14.06, rhel 5,6, and 7.5, centos 7.4 and 7.5 , windows 7 ultimate, and windows 10 pro, on hardware from basic intel desktop pc (core i5), amd phenom II x6, opteron 22xx sunfire servers, dl385 g5, g6 and g8 servers.
So far all of these act exactly the same way.

Please fix this so xeoma will allow my system logs to be in local time with xeoma events and emails!

Hello! Thank you for all the clarifications, we'll add this to the Development Plan. Although we fail to see the relevance of intentionally creating a discrepancy between the hardware clock and the system time. Software-wise this is asking for trouble

- "Although we fail to see the relevance of intentionally creating a discrepancy between the hardware clock and the system time. Software-wise this is asking for trouble." -

There are very valid and universal reasons, think NTP. The whole basis is that hardware time is set to the universal reference.
For time to be correct in any system, the hardware clock must be set to a reference (UTC) and the offset from that reference is the local time. This allows the system to provide logs in local time rather than reference time. This allows applications that use refrence time to work properly. One common example is SMTP, all messages are sent with a timestamp in reference time with the sending servers offset. This allows a receiving server to know if the email is valid by checking timestamps.
Another common and major reason is in a common log repository server, all logs are sent using reference time and the log server adjusts the log time to system time based on offsets. Now if your security server has the reference time set to local and your logserver is in another timezone your events will be skewed. All reference time must be the same and the time zones set correctly per servers locality to ensure that the servers are synchronized.
From our experience, tracking what a person has done and correctly locating the logs for proof is paramount to ensuring that there are no loopholes in our arguement. The timestamps of the logs must match the timestamps in the video, or there is doubt (legally speaking).

I have personally reviewed a lot of surveillance software and for the price, features and flexibility, Xeoma has come out on top (personal rating, others may choose to ignore). I actively demonstrate Xeoma to my clients, show them there is a future path and how well it works, until we send an email that shows up saying it is 'X' hours old or in the future, which may not show up as spam filters are adopting email-from-future demerits.