Hello,

looking now at the patch on the tracker (which somehow was assigned to me), I see few issues and have some questions:

- the tm variable is declared set, but not used - tz is also not used, gettimeofday() can take NULL as second parameter and iirc, tz is obsolete - I wonder if gettimeofday() can actually fail and return code should be checked for error cases - the names of the new column, respectively 'time_hires' sounds a bit strange to me, does it have any special meaning the word 'hires'?

Overall, wouldn't be better to keep the seconds and microseconds (as returned in a timeval structure) in separate columns. That means keeping the time column as it is and adding a new column for microsecs. Then people can get the precision as they want, including only down to the miliseconds if that is what they need.

I will add these notes on the tracker so it can be continued there for development.

As a quick solution for now, one can store the value of $TV(Sn) (taken at 200ok for INVITE or BYE, stored in avp for example) - it is string, but can be converted to number by billing apps.

- http://www.kamailio.org/wiki/cookbooks/4.0.x/pseudovariables#timeval

Cheers, Daniel

On 4/23/13 10:54 AM, Andreas Granig wrote:

Hi Uri,

On 04/23/2013 10:45 AM, Uri Shacked wrote:

...

can anyone tell me if it is possible to save the time and date using accdb (mysql) with milisec as well? the field on the DB is set as TIMESTAMP.

We've opened a ticket on the bug tracker some months ago, but it's still open at http://sip-router.org/tracker/index.php?do=details&task_id=163&proje... and we haven't followed up on it, however we're using this patch in production for months at all our deployments without any issues.

Andreas

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hello,

On 4/23/13 9:44 PM, Andreas Granig wrote:

[...]

...

• the names of the new column, respectively 'time_hires' sounds a bit

strange to me, does it have any special meaning the word 'hires'?

It's "hires" as in "high resolution" for the timestamp value.

the result was reading quite strange, though.

...

Overall, wouldn't be better to keep the seconds and microseconds (as returned in a timeval structure) in separate columns. That means keeping the time column as it is and adding a new column for microsecs. Then people can get the precision as they want, including only down to the miliseconds if that is what they need.

The time column is still being filled as usual, so you can just stay with that format. However, the problem with this column is its date-time format, which causes lots of problems for calls going over daylight saving time changes and when it comes to handling different time zones in general, so time_hires uses a unix-timestamp with 3 digit precision, which makes this much easier to handle. And then again, if you want to use the time_hires column, you can still do from_unixtime in mysql to get a normal datetime format in seconds precision, no need to handle seconds and milliseconds separately.

I see your point related to datetime format for time column.

Still pondering why limit to milisecs when having access to microsecs -- might not be a requirement of such precision in any country, but could be used for stats or even someone will request it at some point in future. So I would rather add two columns with secs and microsecs. Now thinking that using one column with type double might create troubles to some db drivers -- the pros are safe with db drivers and no issues in float/double type precision, the cons is using two columns to get duration.

Cheers, Daniel