fix: accept a space before a utc offset in timestamp literals - #376
Open
anjeongkyun wants to merge 1 commit into
Open
fix: accept a space before a utc offset in timestamp literals#376anjeongkyun wants to merge 1 commit into
anjeongkyun wants to merge 1 commit into
Conversation
Snowflake takes '2026-01-01 10:00:00 +09:00', duckdb reads the offset as a time zone name and raises Unknown TimeZone '+09:00'. It parses the same value without the space, so the space is dropped for string literals cast to timestamp_tz or timestamp_ltz. ConversionException also wasn't translated in _execute, so it surfaced as a server error. Clients retry those: the python connector repeated one failing insert 333 times. It's now a ProgrammingError with 100035 / 22007, matching what a real account returns. Refs tekumara#372
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.
Two parts, both from #372.
The space. Snowflake takes
'2026-01-01 10:00:00 +09:00', duckdb reads the offset as a time zone name and raisesUnknown TimeZone '+09:00'. It parses the same value fine without the space, sotimestamp_offsetsdrops it for string literals cast totimestamp_tzortimestamp_ltz, which also coversto_timestamp_tz(). All four shapes Snowflake documents now work, and the offset is applied rather than ignored.The 500.
ConversionExceptionwasn't in the list of duckdb exceptions translated in_execute, so anything it raised surfaced as a server error. Clients treat that as retryable: the python connector repeated one failing insert 333 times, the JDBC driver 7. It's now aProgrammingErrorwith100035 / 22007, which is what a real account returns for an unrecognised timestamp.Not covered: a literal in
INSERT INTO t VALUES ('2026-01-01 10:00:00 +09:00'). There's no cast to hang the rewrite off, and knowing the target column type means reaching for the schema, which the transforms don't do. It fails with the error above rather than a 500 now. Happy to look at it if you have a preference for how, otherwise it seemed better left out of this change.Rendering the stored offset back is still option 2, untouched here.
Refs #372