23 Apr
2013
23 Apr
'13
11:45 a.m.
Hi,
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.
BR,
Uri
23 Apr
23 Apr
11:54 a.m.
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&proj…
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
9:51 p.m.
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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&proj…
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
10:44 p.m.
Hi Daniel,
On 04/23/2013 08:51 PM, Daniel-Constantin Mierla wrote:
- 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
I'll check with my colleagues regarding these questions and regarding a
final patch, as it might have been modified in the meanwhile (the "live"
version is at https://github.com/sipwise/kamailio).
- 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.
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 will add these notes on the tracker so it can be continued there for
development.
Alright, we'll continue from there and push this forward also on our
side to get it to upstream.
Andreas
11:50 p.m.
Hello,
On 4/23/13 9:44 PM, Andreas Granig wrote:
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
[...]
the result was reading quite strange, though.
- 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.
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.
24 Apr
24 Apr
8:23 a.m.
New subject: save accdb records with milisec in timestamp field
Hi,
As Daniel wrote, the easiest way (if you start from scratch) will be to set
a new field in DB for millisecond and take it from the message.
Another option will be to install MYSQL version 5.6+ (has support for
millisecond in datetime), create a field of datetime and set it "now()".
The problem, with this is that the time is the time that the data was
inserted to DB.....
Is the limit for millisecond is in the ACCDB module? Or it will work with
millisecond if the DB supports it?
If the limit is in the ACCDB, I think it is better to change it there…
Thanks for the replies,
Uri
On Tue, Apr 23, 2013 at 11:45 AM, Uri Shacked <ushacked(a)gmail.com> wrote:
Hi,
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.
BR,
Uri
4233
days inactive
4234
days old
5 comments
3 participants
participants (3)
-
Andreas Granig -
Daniel-Constantin Mierla -
Uri Shacked