[SR-Users] rfc: accounting records time details

Daniel-Constantin Mierla miconda at gmail.com
Thu Sep 5 13:49:28 CEST 2013


For the records, this has been implemented in master branch - a matter 
of time_mode parameter for acc, time value can be stored in various formats.

Cheers,
Daniel

On 5/10/13 9:50 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> any more comments on time storage for acc records?
>
> Obviously, it has to be done via something that is configurable and 
> extensible.
>
> If no more comments, I will go ahead and develop soon a configurable 
> framework for seconds and seconds, microseconds, then others can come 
> and add more.
>
> Cheers,
> Daniel
>
> On 5/1/13 11:08 AM, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> On 4/29/13 2:15 PM, Andreas Granig wrote:
>>> Hi,
>>>
>>> On 04/29/2013 11:47 AM, Thilo Bangert wrote:
>>>> I'd just save one timestamp, ie TAI64 or as java does miliseconds 
>>>> since epoch,
>>>> in a single, new field. saving the timestamp in two fields seems 
>>>> messy.
>>>
>>> Agreed.
>>
>> the option to get current format is a must, there are many tools 
>> depending on how acc records are written now. The idea is to add a 
>> mechanism that allows people to store other formats that may prefer. 
>> Moving from current datetime format to a single different forma value 
>> is not a good decision.
>>
>>>
>>>> miliseconds since epoch is probably preferable, since it can be 
>>>> converted to
>>>> human readable dates by the database server.
>>>
>>> What I like about the DECIMAL approach is that it's (at least in 
>>> MySQL) usable with from_unixtime functions, in case you need quick 
>>> access to human readable format. Up until 5.1 it only shows seconds 
>>> precision in that case, not sure about high resolution precision in 
>>> 5.6 where timestamp seems to support microseconds.
>>>
>>> Also not sure about compatibility with other DB engines.
>> It doesn't look at all as the only format to use. But it can be an 
>> option to store, having its own good benefits, however it is now 
>> spread considering existing stable os deployments. Again, it may 
>> require going through other modules, the db connectors.
>>
>> Cheers,
>> Daniel
>>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
   - more details about Kamailio trainings at http://www.asipto.com -




More information about the sr-users mailing list