fix(core): parse fixed-offset timezones in timestamp logical types - #8950
Open
jackylee-ch wants to merge 1 commit into
Open
fix(core): parse fixed-offset timezones in timestamp logical types#8950jackylee-ch wants to merge 1 commit into
jackylee-ch wants to merge 1 commit into
Conversation
jackylee-ch
force-pushed
the
fix/timestamp-fixed-offset-timezone
branch
from
September 2, 2026 14:02
bce54f6 to
c7b20f6
Compare
![lance-gatekeeper[bot]](https://avatars.githubusercontent.com/in/4433141?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
lance-gatekeeper
Bot
added
the
K-approved
jackylee-ch
force-pushed
the
fix/timestamp-fixed-offset-timezone
branch
from
September 2, 2026 14:37
c7b20f6 to
6e948b8
Compare
lance-gatekeeper
Bot
removed
the
K-approved
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
lance-gatekeeper
Bot
added
the
K-approved
The logical type writes a timestamp's timezone verbatim, so Timestamp(Microsecond, "+08:00") is encoded as "timestamp:us:+08:00". The parser split that string on ':' and required exactly three segments, but the offset contributes a fourth, so the parse failed and Field::data_type, which unwraps it, panicked instead of erroring. Rejoin the trailing segments, matching what the neighbouring fixed_size_list arm already does for the same reason. Only the read side changes; the encoding is untouched.
jackylee-ch
force-pushed
the
fix/timestamp-fixed-offset-timezone
branch
from
September 3, 2026 02:49
6e948b8 to
919d153
Compare
lance-gatekeeper
Bot
removed
the
K-approved
lance-gatekeeper
Bot
added
the
K-approved
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.
A timestamp column whose timezone is a fixed offset cannot be read back. The logical type writes the timezone verbatim, so
Timestamp(Microsecond, "+08:00")is encoded astimestamp:us:+08:00, but the parser split that string on:and required exactly three segments. The offset contributes a fourth, so the parse failed andField::data_type, which unwraps it, panicked instead of returning the error.pyarrow produces this shape routinely:
pa.timestamp("us", tz="+08:00"), and any pandas column localized to a fixeddatetime.timezonecarries+08:00too. Named zones such asUTCand offsets written without a colon (+0800) were unaffected.The fix rejoins the trailing segments, matching what the neighbouring
fixed_size_listarm already does for the same reason. Only the read side changes; the encoding is untouched. The tests cover each time unit against every timezone spelling, both directions, and the field and schema round trips a write performs.