Felenasoft

Hi all,

I purchased a Xeoma license for ubuntu 64 bit. The software is very very cool and it runs with most of my ipcameras but I think I found a bug.

As you can see in the screenshot (see red zones) server time is different from time printed on image and this causes a problem when you schedule your actions in xeoma.

Also the very strange thing is that in xeoma's module the hour is correct according to server time.

How can I resolve it?

thank you

Welcome to the time zone issue caused by DST. A few people on the forum are waiting for Felenasoft to fix this. See

http://felenasoft.com/forum/viewtopic.php?f=8&t=1182

Me too have this issue.

XeoMax Wrote:Me too have this issue.

I hope Felenasoft fixes this soon. They've known about it for awhile.

Hello! This week the new beta-version of Xeoma will be released. We have fixed the issue with time zones, so please make sure to download the new beta here: http://felenasoft.com/xeoma/en/download/

I have made the time to provide some experiments regarding the time issue. Specifically the emailer send time being vastly wrong and forcing us to go looking for the new email that's time stamped several hours wrong.

Setup:
server:
Debian 8.8 on a Xenserver VM hardware virtualized not para. 4GB ram, 2VCPU with regular priorities, testing server has 4 nics bonded into one with lacp to Cisco 3750G switch
updated and upgraded OS to ensure we are not working with out of date files and programs.
no desktop system

Xeoma 17.5.5 standard release with 4 regular licenses activated, no pro features

client:
windows 7 Ultimate, 4GB ram, MS-Office 2016 Outlook

Issue:
The system was setup with hardware clock on UTC - no daylight savings, TZdata set to correct timezone of utc -6. Xeoma timezone was set to CST -6 no daylight savings.
the system shows correct local time, xeoma shows correct local time. on emailing of a trouble, the timestamp is 12 hours behind the correct local time. even though the message body includes the correct time of event.

attempts:
1) setting xeoma to UTC +/-0 and rebooting does not adjust the email timestamp nor does it affect the time in the message body.
2) leaving Xeoma as above, I set the server tzdata to UTC +/-0 and rebooted, this pushed the email time stamp even farther out by another 6 hours.
3) set tzdata to utc+12 and the emailer now emails with correct timestamp, but now event times are out by 6 hours.
4) set Xeoma timezone to correct utc-6 and now all timestamps are correct. just 24hours behind, now the date is wrong on just the emails
5) set tzdata to utc-12 and now all date and time stamps are correct.

Final config:
server must be set to UTC before the tzdata is modified. then modify tzdata to get correct local time/dates in Xeoma email test, system local time will not be correct.
sett xeoma to the correct time zone. retest emails to ensure that they are showing the correct time/date in the email headers as well as the message body.

conclusion:
I am guessing in the Xeoma code is a bit of math to set the date and time based off the system local time. The calculations are apparently wrong and Xeoma is not using the local time at all.
If this was my piece of code, I would just get rid of the code that calculates the time and date and just use the systems local time. This forces the issue to be corrected and ensures that the system is using the correct time/date. All of which can be kept synchronized with NTP, either a local NTP server or an internet NTP server. This also handles the issue of daylight-savings time not adjusted, but still keeps the issue of daylight-savings fall back overwrite which can be handled by letting the user specify the start/stop dates for daylight savings and modifying the system to add DST to the archive name while daylight-savings time is in effect.

Now that there is a method to "patch" this issue, FelenaSoft please fix this as it is a requirement for archive file timestamps and video timestamps match for legal reasons. This means that system, system local and xeoma timestamps must all be correct and in alignment for the authorities to be able to use this video evidence as fact of law. The above work-around makes the video evidence non-credible and a judge can dismiss the evidence.

I have a small correction, the email test in the emailer config sends the correct date/time, but the event message is now displaying the server local time after a final system reboot.

I can live with this for now as at least the emails are not buried in my inbox, but it is not ideal and needs to be addressed properly and as a priority.