10 May
2013
10 May
'13
10:50 a.m.
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:
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 Training, San Francisco, USA - June 24-27, 2013
* http://asipto.com/u/katu *
Hi,
On 04/29/2013 11:47 AM, Thilo Bangert wrote:
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.
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. 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.