I was testing with the newest demo to get the data, everything went well and started programming in PHP with the data, but i found some kind of bug…
The timestamps that is given with the data is 2 hours behind servertime, this while the alarm_log and active_alarms give the right timestamp.
I tried to change the servertime and started again. Then the timestamps are on the exact time they have to be only the alarm_log and active_alarms changed also and are 2 hours later…
Is this a known bug?
This is certainly worth investigating. Could you provide more info about you setup?
Are the logging group and alarm history running on the same datasource?
Is the FactorySQL service running on the same computer as the SQL database?
If not, could you verify the Windows timezone settings on both computers.
Hi-
So, the big difference is that the groups’ timestamps are generated at the DB level, using the db’s CURRENT_TIMESTAMP, whereas the times for the alerts are generated on the machine running FSQL. On our end, it would be better to have both be generated at the DB, but the current method provides slightly better accuracy, time zone issues aside.
I would have to guess that your timezone settings are different between the 2 machines. If you could set them equal, and that fixes the problem, then it’s the easiest solution for now. If this doesn’t work, or isn’t possible for some reason, let us know and we can look into other options.
Regards,
It looks like i founded the cause of the problem,
My current MySQL settings getting GMT time instead of the right timezone, Everytime i restart MySQL the current time is GMT time again.
Setting the Global 2 hours futher gives the right timestamp.
SET GLOBAL time_zone = ‘+2:00’;
Maybe it is handy to put an option to create the timestamp in FactorySQL instead of use the timestamp of the MySQL server with another timezone so users can choose them how to create it.