Instead of using the time2str routines that go through timezone conversion in kamailio, let MySQL do it. This helps with the sipcapture module in case the system time is CET but the database is operated in UTC. In these cases the micro_ts and date columns would be offseted by the timezone difference and look-ups fail to work. You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/957
-- Commit Summary --
* db_mysql: Let the database convert the timestamp
-- File Changes --
M src/modules/db_mysql/km_val.c (18)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/957.patch https://github.com/kamailio/kamailio/pull/957.diff
@adubovikov
for me it's ok @miconda ?
I think this can be added only as a modparam and disabled by default, because it can break the other modules that expect to store the server timestamp, like usrloc (location table), acc, msilo.
@miconda you are right,
https://github.com/kamailio/kamailio/blob/master/src/lib/srdb1/db_ut.c#L211-...
db_str2time expects the "original timestamp" in the kamailio's timezone.
@zecke can you please make it configurable ?
Made it configurable but I have not tested/inserted data in a production system yet. So please wait for a second. I tried to update the documentation with the new parameter as well.
Okay it seems to work (on and off) of that setting. Used hepgen.js to send some data and had a breakpoint in the code in km_val.c and it was triggered (or wasn't depending on the global setting). _s also looked sane.
Holger Freyther writes:
Made it configurable but I have not tested/inserted data in a production system yet. So please wait for a second. I tried to update the documentation with the new parameter as well.
Are we in frozen state with no new features to trunk?
-- Juha
@juha-h -- this seems to fix an issue when kamailio server (for sip routing) is different than kamailio server (for sipcapture). Overall is no change in the default behaviour, just a switch to choose the preferred date/time handling. It will be merged in master branch as the branch 5.0 was already created. But I will consider it for backporting if it looks clean and simple.
Merged #957.
Thank you.
-
Alexandr Dubovikov -
Daniel-Constantin Mierla
-
Holger Freyther
-
juha-h