[sr-dev] [SR-Users] rfc: accounting records time details

[Alex Hermann]

On Monday 29 April 2013 11:05:36 Daniel-Constantin Mierla wrote:
> Here are some suggestions presented so far.
> 
> 1) store seconds.miliseconds as double - there is a patch (which

Please do not use floating point respresentations for values that will be used 
in accounting. Floating point is imprecise. As the time related columns will 
most probably be used for billing, the values should be exact. In SQL this 
means using the DECIMAL or NUMERIC column type.


> 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)

Difficult to use in calculations.


> Any other suggestions?

3) Use native mili/microseconds support for DATETIME or TIMESTAMP in the 
database. At least MariaBD and PostgreSQL support this.

4) Store mili/microseconds since epoch in a BIGINT column.


> 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
 - bit three set - store seconds.miliseconds as DECIMAL value in one column
 - bit four set - add mili/microseconds to DATETIME (only valid when bit 1 is 
set too)
 - bit five set - store mili/microseconds since epoch as BIGINT value in one 
column


Alternatively, 2 settings can be used, one for storage format and one to 
choose the precision/resolution. This provides the most flexibility for the 
user.

timestamp_format:
  datetime (TIMESTAMP or DATETIME)
  epoch ((BIG)INT or DECIMAL, depending on resolution)
  split_epoch (2x INT)

timestamp_resolution: seconds, miliseconds, microseconds

Default would be the current situation: datetime + seconds


-- 
Greetings,

Alex Hermann