Repository navigation
fix: correct timezone handling in datetime-based integration tests - #334
Merged
Merged
Conversation
Format("...Z") only appends a literal Z, it doesn't convert to UTC. When
formatting a Local time.Time this way, the RFC3339 parser on the other
side reads the string as UTC, shifting the parsed instant by the host's
UTC offset. This made TestConsumeFromTimestampIntegration and
TestResetCGOToDatetimeIntegration fail on any non-UTC machine (e.g. CI
runs in UTC so it never surfaced there). Calling .UTC() before
formatting makes the literal Z accurate.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
TestConsumeFromTimestampIntegrationandTestResetCGOToDatetimeIntegrationfail when run on any machine whose local timezone isn't UTC (e.g.make integration_teston a dev laptop set to Europe/Berlin), while passing fine in CI (which runs in UTC).Root cause: both tests build a filter timestamp via
time.Time.Format("2006-01-02T15:04:05.000Z"). The trailingZin that layout is not a timezone-conversion directive (onlyZ07:00/Z0700are) — it's just a literal character. Formatting a Localtime.Timewith it therefore produces the local wall-clock string with a misleadingZsuffix that looks like UTC but isn't.On the parsing side,
internal/util.ParseTimestamptriestime.RFC3339first viatime.ParseInLocation(time.RFC3339, s, Local). Since the input string'sZmatches RFC3339'sZ07:00zone verb, Go treats it as an explicit UTC marker and ignores theLocallocation argument (this is documentedParseInLocationbehavior: an explicit zone in the input always wins over the passed-in location). The result: the parsed cutoff is off by exactly the host's UTC offset, shifting the query window away from the actual message timestamps and making both tests get empty results.Fix: call
.UTC()before formatting, so the literalZis accurate.Type of change
Testing
TZ=UTC.go test -short ./...and the fullcmd/consume/cmd/resetintegration suites against a local docker-compose Kafka cluster — all pass.golangci-lint runclean.Test-only change, no user-facing behavior affected, so no CHANGELOG entry.
🤖 Generated with Claude Code