[sr-dev] rfc: accounting records time details

Daniel-Constantin Mierla miconda at gmail.com
Mon Apr 29 11:05:36 CEST 2013


Hello,

there were old and recent discussions about the representation of time 
in accounting records. At this moment the acc module stores the unix 
timestamp as datetime value.

In some countries is required to store more accuracy, beyond the 
seconds. Also, the datetime gives some troubles with converting back to 
unix timestamp, specifically with time zones and daylight saving times.

I want to open a discussion that is visible for all users and devs, 
being something affecting probably everyone, input from anyone that is 
interested being relevant to select the right approach.

Here are some suggestions presented so far.

1) store seconds.miliseconds as double - there is a patch (which 
probably needs some tunings itself) on tracker. The precision is shifted 
from seconds to milliseconds. Internally computed from microseconds from 
timeval structure. The other modules might need updates (iirc dbtext has 
only 2 decimals precisions for double, while miliseconds will require at 
least three -- could be the case for flatstore or other modules).

Advantage is the computing of duration directly by subtraction of two 
values.

2) store seconds and microseconds as two separate values. Should be no 
issues with existing modules. Even more accuracy than above, no issues 
with other modules, but will require to use two columns (thus four 
values to compute the duration)

Any other suggestions?

Personally, at this moment, I will go with 2), but that might not meet 
everyone's needs. So a solution can be to make it configurable, as a 
bitmask of what time representation to store.

Say, there will be a new parameter  timestamp_mode for acc module:
- bit one set - store seconds timestamp as for now (default)
- bit two set - store seconds and microseconds in separate integer columns
- bit three set - store seconds.miliseconds as double value in one column

I could add the parameter and tune acc for bit one and two. For bit 
three a deeper review is needed for other modules, probably the 
developer that submitted to the tracker can do it.

More suggestions? Pro or cons opinions?

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24016, 2013
   * http://asipto.com/u/katu *




More information about the sr-dev mailing list