New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

io.reftek: switch internal representation of timestamps to integer #2038

Merged
merged 9 commits into from Jan 12, 2018

Conversation

Projects
None yet
1 participant
@megies
Member

megies commented Jan 8, 2018

..nanoseconds to avoid any floating point precision issues

What does this PR do?

Changes internal timestamp representation of Reftek130 packets from floats to integers.

Why was it initiated? Any relevant Issues?

Fixes #2036.

PR Checklist

  • Correct base branch selected? master for new fetures, maintenance_... for bug fixes
  • This PR is not directly related to an existing issue (which has no PR yet).
  • If the PR is making changes to documentation, docs pages can be built automatically.
    Just remove the space in the following string after the + sign: "+ DOCS"
    only changes low-level objects/private functions
  • If any network modules should be tested for the PR, add them as a comma separated list
    (e.g. clients.fdsn,clients.arclink) after the colon in the following magic string: "+TESTS:"
    (you can also add "ALL" to just simply run all tests across all modules)
  • All tests still pass.
  • Any new features or fixed regressions are be covered via new tests: should add regression test
  • Any new or changed features have are fully documented. no new features
  • Significant changes have been added to CHANGELOG.txt .
io.reftek: switch internal representation of timestamps to integer
nanoseconds to avoid any floating point precision issues

@megies megies added the .io label Jan 8, 2018

@megies megies added this to the 1.1.1 milestone Jan 8, 2018

megies added some commits Jan 8, 2018

io.reftek: avoid sorting packages when packet sequence rolls over from
max to 0 again

also use package time in sorting packages
io.reftek: after reading the file, do a cleanup merge
that might help in some strange situations to avoid separate traces when
there isn't a gap actually
@megies

This comment has been minimized.

Show comment
Hide comment
@megies

megies Jan 8, 2018

Member

Actually, it turns out the switch to internal integer nanoseconds time representations was not necessary to fix #2036 avoiding to sort the package list (which was done due to the package sequence rollover from 9999 to 0) would have been enough.

But nevertheless, using the integer representation seems safer, so I'll keep it this way.

Member

megies commented Jan 8, 2018

Actually, it turns out the switch to internal integer nanoseconds time representations was not necessary to fix #2036 avoiding to sort the package list (which was done due to the package sequence rollover from 9999 to 0) would have been enough.

But nevertheless, using the integer representation seems safer, so I'll keep it this way.

megies added some commits Jan 9, 2018

io.reftek: when printing packet info correctly convert all time
properties from internal integer POSIX nanoseconds to UTCDateTime
io.reftek: restore old default in current tests (sorting the artifically
permuted packet sequence in the test file)
@megies

This comment has been minimized.

Show comment
Hide comment
@megies

megies Jan 9, 2018

Member

There's a minimal change in UTCDateTime, but I think this is no problem to go into maintenance branch.

88faf58#diff-5c81ae2e2a30581bc31995261142c034R387

Member

megies commented Jan 9, 2018

There's a minimal change in UTCDateTime, but I think this is no problem to go into maintenance branch.

88faf58#diff-5c81ae2e2a30581bc31995261142c034R387

@megies

This comment has been minimized.

Show comment
Hide comment
@megies

megies Jan 9, 2018

Member

I think there won't be a regression test for this.. the problem appears deep into the file and I didn't manage to reproduce the problem just cutting out those seemingly offending packages and slapping the original header packet onto them.. so having a regression test with a small test file would mean serious tinkering with the original huge file provided by the OP and no idea how long that would take me.

Member

megies commented Jan 9, 2018

I think there won't be a regression test for this.. the problem appears deep into the file and I didn't manage to reproduce the problem just cutting out those seemingly offending packages and slapping the original header packet onto them.. so having a regression test with a small test file would mean serious tinkering with the original huge file provided by the OP and no idea how long that would take me.

@megies

This comment has been minimized.

Show comment
Hide comment
@megies

megies Jan 12, 2018

Member

CI was passing, so merging..

Member

megies commented Jan 12, 2018

CI was passing, so merging..

@megies megies merged commit c6a686f into maintenance_1.1.x Jan 12, 2018

0 of 3 checks passed

ci/circleci CircleCI is running your tests
Details
continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details

@megies megies deleted the fix_reftek_float_issues branch Jan 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment