#181 Timestamp granularity of seconds is insufficient

core (47)

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.


  • Dynamic Packet

    Dynamic Packet - 2011-02-25

    adds $Tsms to core, representing time in MILLISECONDS

  • Bogdan-Andrei Iancu

    • priority: 5 --> 3
    • assigned_to: nobody --> bogdan_iancu
    • status: open --> open-invalid
  • Bogdan-Andrei Iancu


    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.


  • Bogdan-Andrei Iancu

    • priority: 3 --> 5
    • milestone: --> trunk
    • assigned_to: bogdan_iancu --> vladut-paiu
  • Bogdan-Andrei Iancu

    let's make a function that returns into 2 vars the secs and usecs.

  • Vladut-Stefan Paiu

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

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks