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