Fix timestamp/time type handling in diff and repair pipelines#78
Fix timestamp/time type handling in diff and repair pipelines#78mason-sharp merged 2 commits intomainfrom
Conversation
mason-sharp
commented
Feb 17, 2026
- Split combined timestamp/timestamptz case in ConvertToPgxType; return pgxv5type.Timestamp for "timestamp without time zone" so pgx sends the correct wire type
- Add time/timetz support: serialize pgxv5type.Time in diff output, parse time strings back to pgxv5type.Time in ConvertToPgxType, and pass timetz as string (unregistered in pgx v5 type map)
- Exclude "time with time zone" from IsKnownScalarType so the diff layer casts it to ::TEXT (avoids scan error on unregistered type)
- Wrap time.Time in pgxv5type.Timestamp in repair's convertValueForType for timestamp-without-tz columns
- Add unit tests for all new type handling paths
- Add integration test exercising full diff→repair round-trip for all four temporal types
- Split combined timestamp/timestamptz case in ConvertToPgxType; return pgxv5type.Timestamp for "timestamp without time zone" so pgx sends the correct wire type - Add time/timetz support: serialize pgxv5type.Time in diff output, parse time strings back to pgxv5type.Time in ConvertToPgxType, and pass timetz as string (unregistered in pgx v5 type map) - Exclude "time with time zone" from IsKnownScalarType so the diff layer casts it to ::TEXT (avoids scan error on unregistered type) - Wrap time.Time in pgxv5type.Timestamp in repair's convertValueForType for timestamp-without-tz columns - Add unit tests for all new type handling paths - Add integration test exercising full diff→repair round-trip for all four temporal types Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughAdds handling and conversion for PostgreSQL temporal types (TIMESTAMP, TIMESTAMPTZ, TIME, TIMETZ) to diff and repair code paths, introduces parsing helpers for timestamps and times, and expands unit and integration tests to verify pgx v5 type wrapping and SQL generation. Changes
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pkg/common/utils.go`:
- Around line 28-29: parseTimeToMicroseconds currently accepts out-of-range
hour/minute/second values and fractional seconds with more than 6 digits; update
parseTimeToMicroseconds to validate that hour is 0–23, minute and second are
0–59 (or explicitly document/handle leap-second 60 if desired), reject
non-numeric components, and return an error for invalid ranges. For fractional
seconds, accept up to 6 digits by truncating (not rounding) extra digits or
padding with zeros to 6 digits before converting to microseconds, and ensure the
final microsecond count is computed from validated parts; make these checks and
truncation inside parseTimeToMicroseconds and propagate an error instead of
silently producing incorrect values.
Reject out-of-range hours (>23), minutes (>59), and seconds (>59). Truncate fractional second digits beyond 6 to microsecond precision. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
🧹 Nitpick comments (1)
pkg/common/utils_test.go (1)
131-168: Consider asserting parsed time values in format/precision tests.
TestConvertToPgxType_TimestampWithPrecisionandTestConvertToPgxType_TimestampFormatsverify that the correct type is returned andValid == true, but don't assert the actual parsedTimefield. For the precision test this is fine, but for the formats test, asserting known expected values for at least one or two cases would catch silent mis-parses (e.g., a format that parses "10:30" as "00:00" and still returnsValid: true).Not blocking — the current tests still add meaningful coverage.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pkg/common/utils_test.go` around lines 131 - 168, Update the timestamp tests to assert actual parsed time values in addition to type/Valid checks: in TestConvertToPgxType_TimestampWithPrecision and TestConvertToPgxType_TimestampFormats call ConvertToPgxType (already used) then cast to pgxv5type.Timestamp and compare ts.Time (or ts.Time.UTC()) to expected time.Time values for at least one or two formats (e.g., the "RFC3339" case and one offset/space-separated case) using time.Equal or UTC-normalized equality; keep the existing type and Valid assertions and fail the test if the parsed time does not match the expected value.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@pkg/common/utils_test.go`:
- Around line 131-168: Update the timestamp tests to assert actual parsed time
values in addition to type/Valid checks: in
TestConvertToPgxType_TimestampWithPrecision and
TestConvertToPgxType_TimestampFormats call ConvertToPgxType (already used) then
cast to pgxv5type.Timestamp and compare ts.Time (or ts.Time.UTC()) to expected
time.Time values for at least one or two formats (e.g., the "RFC3339" case and
one offset/space-separated case) using time.Equal or UTC-normalized equality;
keep the existing type and Valid assertions and fail the test if the parsed time
does not match the expected value.