Open jpawlowski opened 11 years ago
This is not going to be a shop stopper for 5.0. We can fix that in a 5.0.1.
Which URLs are affected by this problem?
e.g. call histories
@spag Please verify if this is a FreeSWITCH/Lua problem.
Looking at my analysis results this is not a FS/lua problem as FS writes the correct timestamps into the database:
The call_histories table is probably a bit misleading and does not reveal the right culprit. The corresponding Lua library simply calls the FROM_UNIXTIME() MySQL function to save the time values provided as simple integer values by FreeSWITCH.
Hmmmm could it be that FROM_UNIXTIME is always UTC? If that would be the case we might need to find a workaround here
Currently there is a lack of 1 hour between the logged time in the web GUI's call history and the actual time the call occurred.
The host system is set to local time Europe/Berlin (CET) and system command
date
shows correct local time. MySQL uses it's standard setting default-time-zone=SYSTEM which should rely on the system setting.However the web GUI still shows a difference of 1 hour.
Workaround currently is to set MySQL's default-time-zone='+00:00' which sets MySQL to UTC which drifts MySQL away from system log files. It's also likely that this setting is not safe for summer time or other time zones but more a hack for hour CET timezone. I also added MySQL timezone tables mentioned here so MySQL has full support to handle timezones correctly: http://dev.mysql.com/doc/refman/5.5/en/time-zone-upgrades.html
It seems the webgui and also xml phone exports use a wrong timezone setting or so.
Comparisons:
default-time-zone=SYSTEM
default-time-zone='+00:00'
The webgui should show the same information as we have in the database. What WOULD be a good improvement though is to respect the visitors browser setting and to recalculate the time accordingly, e.g. by using the MySQL function mentioned in the link above.