Timestamp format should be reviewed

[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:

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.