test: send correct time unit

[NguyenHoangSon96]

Closes #

Proposed Changes

• When setting Point timestamp to new Date(), the timestamp sent to the servers will be converted to precision set in WriteOptions.
• Add more tests for these new changes.

Checklist

• CHANGELOG.md updated
• Rebased/mergeable
• A test has been added if appropriate
• Tests pass
• Commit messages are conventional
• Sign CLA (if not already signed)

[Copilot]

Pull request overview

Fixes a bug where Point timestamps set via new Date() were always serialized in nanoseconds, even when the configured WriteOptions.precision (and the resulting precision query parameter on the write request) was s/ms/us. The change threads precision from InfluxDBClient.write through writableDataToLineProtocol into Point.toLineProtocol, but only applies it when the point's timestamp is a Date, leaving pre-formatted string/number timestamps untouched.

Changes:

• Pass the resolved write precision into writableDataToLineProtocol, and use it for Point.toLineProtocol only when the timestamp is a Date.
• Add unit tests asserting both the URL precision parameter and the serialized timestamp for ns/us/ms/s against both the v3 and v2 write APIs.
• Add an e2e test covering successful writes for all four precisions with setTimestamp(new Date()).

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
packages/client/src/InfluxDBClient.ts	Forward options.precision to writableDataToLineProtocol from write().
packages/client/src/util/generics.ts	Accept optional precision; apply it to Point.toLineProtocol only when timestamp is a Date.
packages/client/test/unit/Write.test.ts	Add four near-duplicate tests verifying timestamp conversion for ns/us/ms/s on v3 and v2 paths.
packages/client/test/integration/e2e.test.ts	Add e2e write test iterating over all precisions with Date timestamps for both v3 and v2 APIs.
CHANGELOG.md	Document the new precision-aware timestamp behavior under Features.

Comments suppressed due to low confidence (2)

packages/client/test/unit/Write.test.ts:121

• Computing the expected nanosecond timestamp as now.getTime() * 1_000_000 performs floating-point multiplication that produces values around 1.7e18, which exceeds Number.MAX_SAFE_INTEGER (~9.0e15). The result loses precision (granularity ~256), so its .toString() will generally not equal the production value, which is computed via string concatenation (${d.getTime()}000000 in dateToProtocolTimestamp.ns, packages/client/src/util/time.ts:97). This assertion is likely to fail or be flaky depending on the current time. Compute the expected value as ${now.getTime()}000000 to mirror the production logic exactly.

            expect(time).equals((now.getTime() * 1_000_000).toString())

packages/client/test/unit/Write.test.ts:112

• The .delay(1000) adds a full second of latency to every iteration of every test (8 iterations across the four tests = ~8s of pure waiting). Combined with .timeout(5000), the multi-iteration tests are at risk of hitting the timeout under any additional latency. The delay also doesn't appear to test any timing-related behavior. Consider removing .delay(1000) (and .persist(), which is unnecessary because each iteration registers a fresh interceptor for a unique path).

          .delay(1000)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.