Skip to content
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

Timestamp conversion does not account for floating point errors #606

Open
revbingo opened this issue Dec 7, 2021 · 0 comments · May be fixed by #607
Open

Timestamp conversion does not account for floating point errors #606

revbingo opened this issue Dec 7, 2021 · 0 comments · May be fixed by #607

Comments

@revbingo
Copy link
Contributor

revbingo commented Dec 7, 2021

Expected Behavior

Given a nano timestamp from Influx of 1638842483690000000, the RFC3339 date in the result set should be 2021-12-07T02:01:23.690Z

Actual Behavior

The resultset contains the timestamp 2021-12-07T02:01:23.689Z.

This is because the timetoDate function divides the nano timestamp by Math.pow(10,6), which due to FP constraints results in 1638842483689.9998

Steps/Code to Reproduce the Problem

  1. Insert a record with the nano second timestamp 1638842483690000000
  2. Use the client to query the record with ms precision. The timestamp will be presented as 2021-12-07T02:01:23.689Z

Pull request incoming...

revbingo added a commit to revbingo/node-influx that referenced this issue Dec 7, 2021
revbingo added a commit to revbingo/node-influx that referenced this issue Dec 7, 2021
@revbingo revbingo linked a pull request Dec 7, 2021 that will close this issue
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant