Skip to content

Timestamp format should be reviewed #47

Open
@bestchai

Description

@bestchai

The timestamps are currently saved in strings. But they are in a format that could be translated into a Date value. Right now we are converting them into Numbers to make operations with them but they are very large numbers and they overflow Javascript's Number format, so the results are not accurate.

E.g. in the picture below, the correct result would be 1100:

Selection_064.png

If the timestamps are generated by counting nanoseconds, i.e. it represents absolute values of nanoseconds, calculating time differences by subtracting Numbers is the right way to go. But if it's generated by date encoding, we should change it so that we perform operations on Date variables.

Action: Check with Prof. Sasha how the timestamps are generated and see if it's best to save it in a Date variable or if we can just operate in those absolute Numbers that are stored in strings.

[Issue created by mhnnunes: 2016-06-08]
[Last updated on bitbucket: 2017-04-17]

[Comment created by grahamstl: 2017-04-17]
In the current version (03f7ab9), the string timestamps are being truncated at the front (removing the first three characters of each) before doing the math in order to generate more accurate results (see the ModelGraph constructor). But if the timestamp format produces timestamps that are too short, this will not work.

The documentation simply says 'physical clock timestamp' but gives no indication for the format or units (at least not on the main page), so there is the possibility that they will use a timestamping procedure that causes this bug to appear. Ideally, our new format will take this into consideration.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions