#181 Timestamp granularity of seconds is insufficient

trunk
closed-fixed
core (47)
5
2011-06-24
2011-02-25
Dynamic Packet
No

Current core options for getting numeric timestamps are limited $Ts (time in seconds) and $Tsm (microseconds of the current second).

This leaves no way to calculate more precise time deltas. Even trying to combine the two current variables, being the results of two separate calls, they are not
equal, rounding issues non-withstanding.

Attached is a patch that creates a new core variable, $Tsms, which represents the current timestamp in MILLISECONDS. This granularity is sufficient for most applications. If more is precision is needed, this could easily be extended to add another var, $Tsus, which would represent current time in MICROSECONDS.

Discussion

  • Dynamic Packet
    Dynamic Packet
    2011-02-25

    adds $Tsms to core, representing time in MILLISECONDS

     
    • priority: 5 --> 3
    • assigned_to: nobody --> bogdan_iancu
    • status: open --> open-invalid
     
  • Hi,

    The approach is invalid as a variable returns numerical vals as integers -> 2^32 = 4294967296 . This is the max number of miliseconds you can store. Considering 1000 milliseconds per second, 3600 seconds per hour, 24 hours per day and 365 days per year -> you can store only miliseconds covering 0.136 years :D....starting from 1970 :P...

    So, the returned value is overflowed big time.....

    I suggest a different approach, having a function that returns (from a single sys call) 2 values, the seconds and microsecs inside the given second.

    Regards,
    Bogdan

     
    • priority: 3 --> 5
    • milestone: --> trunk
    • assigned_to: bogdan_iancu --> vladut-paiu
     
  • let's make a function that returns into 2 vars the secs and usecs.

     
    • status: open-invalid --> closed-fixed