1 May
2013
1 May
'13
12:08 p.m.
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.