From fe8056ffb6e0c5ce8a9a7cc6d795c2eb05675aec Mon Sep 17 00:00:00 2001 From: serramatutu Date: Thu, 30 Oct 2025 12:20:51 +0100 Subject: [PATCH 01/14] Add Timestamp With Offset canonical extension type --- docs/source/format/CanonicalExtensions.rst | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index 8608a6388e0..e6a6cf64e34 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -483,6 +483,28 @@ binary values look like. .. _variant_primitive_type_mapping: +Timestamp With Offset +============= +This type represents a timestamp column that stores potentially different timezone offsets per value. The timestamp is stored in UTC alongside the original timezone offset in minutes. + +* Extension name: ``arrow.timestamp_with_offset``. + +* The storage type of the extension is a ``Struct`` with 2 fields, in order: + + * ``timestamp``: a non-nullable ``Timestamp(time_unit, "UTC")``, where ``time_unit`` is any Arrow ``TimeUnit`` (s, ms, us or ns). + + * ``offset_minutes``: a non-nullable signed 16-bit integer (``Int16``) representing the offset in minutes from the UTC timezone. Negative offsets represent time zones west of UTC, while positive offsets represent east. Offsets range from -779 (-12:59) to +780 (+13:00). + +* Extension type parameters: + + * ``time_unit``: the time-unit of each of the stored UTC timestamps. + +* Description of the serialization: + + Extension metadata is an empty string. + + When de/serializing to/from JSON, this type must be represented as an RFC3339 string, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. + Primitive Type Mappings ----------------------- From 080220a36401e6468f381c241c6dae245c76967d Mon Sep 17 00:00:00 2001 From: serramatutu Date: Mon, 3 Nov 2025 14:19:23 +0100 Subject: [PATCH 02/14] fixe: move timestamp offset to its own section --- docs/source/format/CanonicalExtensions.rst | 44 +++++++++++----------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index e6a6cf64e34..383edf5f949 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -483,28 +483,6 @@ binary values look like. .. _variant_primitive_type_mapping: -Timestamp With Offset -============= -This type represents a timestamp column that stores potentially different timezone offsets per value. The timestamp is stored in UTC alongside the original timezone offset in minutes. - -* Extension name: ``arrow.timestamp_with_offset``. - -* The storage type of the extension is a ``Struct`` with 2 fields, in order: - - * ``timestamp``: a non-nullable ``Timestamp(time_unit, "UTC")``, where ``time_unit`` is any Arrow ``TimeUnit`` (s, ms, us or ns). - - * ``offset_minutes``: a non-nullable signed 16-bit integer (``Int16``) representing the offset in minutes from the UTC timezone. Negative offsets represent time zones west of UTC, while positive offsets represent east. Offsets range from -779 (-12:59) to +780 (+13:00). - -* Extension type parameters: - - * ``time_unit``: the time-unit of each of the stored UTC timestamps. - -* Description of the serialization: - - Extension metadata is an empty string. - - When de/serializing to/from JSON, this type must be represented as an RFC3339 string, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. - Primitive Type Mappings ----------------------- @@ -566,6 +544,28 @@ Primitive Type Mappings | UUID extension type | UUID | +----------------------+------------------------+ +Timestamp With Offset +============= +This type represents a timestamp column that stores potentially different timezone offsets per value. The timestamp is stored in UTC alongside the original timezone offset in minutes. + +* Extension name: ``arrow.timestamp_with_offset``. + +* The storage type of the extension is a ``Struct`` with 2 fields, in order: + + * ``timestamp``: a non-nullable ``Timestamp(time_unit, "UTC")``, where ``time_unit`` is any Arrow ``TimeUnit`` (s, ms, us or ns). + + * ``offset_minutes``: a non-nullable signed 16-bit integer (``Int16``) representing the offset in minutes from the UTC timezone. Negative offsets represent time zones west of UTC, while positive offsets represent east. Offsets range from -779 (-12:59) to +780 (+13:00). + +* Extension type parameters: + + * ``time_unit``: the time-unit of each of the stored UTC timestamps. + +* Description of the serialization: + + Extension metadata is an empty string. + + When de/serializing to/from JSON, this type must be represented as an RFC3339 string, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. + Community Extension Types ========================= From d8b900fd29603a34670ea2e45ae4f8eb5cbc8432 Mon Sep 17 00:00:00 2001 From: serramatutu Date: Mon, 3 Nov 2025 14:21:51 +0100 Subject: [PATCH 03/14] Add note about compat with ANSI SQL --- docs/source/format/CanonicalExtensions.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index 383edf5f949..a45560e2a9b 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -547,6 +547,7 @@ Primitive Type Mappings Timestamp With Offset ============= This type represents a timestamp column that stores potentially different timezone offsets per value. The timestamp is stored in UTC alongside the original timezone offset in minutes. +This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WITH TIME ZONE``, which is supported by multiple database engines. * Extension name: ``arrow.timestamp_with_offset``. From d9a85aa190a61d8fc9e9e95d2bebd5bf55370812 Mon Sep 17 00:00:00 2001 From: serramatutu Date: Fri, 7 Nov 2025 14:32:33 +0100 Subject: [PATCH 04/14] Make RFC3339 JSON a recommendation, not requirement --- docs/source/format/CanonicalExtensions.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index a45560e2a9b..7dc40e07f9c 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -565,7 +565,11 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT Extension metadata is an empty string. - When de/serializing to/from JSON, this type must be represented as an RFC3339 string, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. +.. note:: + + Although not required, it is recommended that implementations represent this type as an RFC3339 string when de/serializing to/from JSON, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. + + The rationale behind this recommendation is that many programming languages provide support for parsing RFC3339 out of the box, facilitating consumption of timezone-aware JSON-encoded arrow arrays without extra boilerplate just for integrating with Arrow. Community Extension Types ========================= From 1bb212f13652947a363cfe2659725a71f3df9845 Mon Sep 17 00:00:00 2001 From: serramatutu Date: Fri, 7 Nov 2025 14:33:27 +0100 Subject: [PATCH 05/14] Add header to make it similar to other extensions --- docs/source/format/CanonicalExtensions.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index 7dc40e07f9c..c02fc50b247 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -544,6 +544,8 @@ Primitive Type Mappings | UUID extension type | UUID | +----------------------+------------------------+ +.. _timestamp_with_offset_extension: + Timestamp With Offset ============= This type represents a timestamp column that stores potentially different timezone offsets per value. The timestamp is stored in UTC alongside the original timezone offset in minutes. From 06ffdf958c34405918300789dd88a1b6ac5684ee Mon Sep 17 00:00:00 2001 From: serramatutu Date: Fri, 7 Nov 2025 14:43:37 +0100 Subject: [PATCH 06/14] Allow dictionary and run-end encodings for the offset --- docs/source/format/CanonicalExtensions.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index c02fc50b247..ae769143922 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -569,9 +569,13 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT .. note:: - Although not required, it is recommended that implementations represent this type as an RFC3339 string when de/serializing to/from JSON, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. + It is also *permissible* for the ``offset_minutes`` field to be dictionary-encoded with a preferred (*but not required*) index type of ``int8``, or run-end-encoded with a preferred (*but not required*) runs type of ``int8``. - The rationale behind this recommendation is that many programming languages provide support for parsing RFC3339 out of the box, facilitating consumption of timezone-aware JSON-encoded arrow arrays without extra boilerplate just for integrating with Arrow. +.. note:: + + Although not required, it is *recommended* that implementations represent this type as an RFC3339 string when de/serializing to/from JSON, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. + + The rationale behind this recommendation is that many programming languages provide support for parsing RFC3339 out of the box, facilitating consumption of timezone-aware JSON-encoded Arrow arrays without extra boilerplate just for integrating with Arrow. Community Extension Types ========================= From 7520684cddda570eded48c0bf690ac6788a80eb3 Mon Sep 17 00:00:00 2001 From: Lucas Valente Date: Tue, 11 Nov 2025 07:32:51 +0100 Subject: [PATCH 07/14] lidavidm's suggestion Co-authored-by: David Li --- docs/source/format/CanonicalExtensions.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index ae769143922..d63d19d181d 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -573,9 +573,9 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT .. note:: - Although not required, it is *recommended* that implementations represent this type as an RFC3339 string when de/serializing to/from JSON, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. + Although not required, it is *recommended* that implementations represent this type as an RFC3339 string when de/serializing to/from JSON, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. - The rationale behind this recommendation is that many programming languages provide support for parsing RFC3339 out of the box, facilitating consumption of timezone-aware JSON-encoded Arrow arrays without extra boilerplate just for integrating with Arrow. + The rationale behind this recommendation is that many programming languages provide support for parsing RFC3339 out of the box, facilitating consumption of timezone-aware JSON-encoded Arrow arrays without extra boilerplate just for integrating with Arrow. Community Extension Types ========================= From b0d9be3be93098e7932236b1e5aa921d3d1c8469 Mon Sep 17 00:00:00 2001 From: serramatutu Date: Thu, 20 Nov 2025 09:48:32 +0100 Subject: [PATCH 08/14] Add section on nullability of inner buffers --- docs/source/format/CanonicalExtensions.rst | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index d63d19d181d..ff1a78efcdc 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -555,9 +555,9 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT * The storage type of the extension is a ``Struct`` with 2 fields, in order: - * ``timestamp``: a non-nullable ``Timestamp(time_unit, "UTC")``, where ``time_unit`` is any Arrow ``TimeUnit`` (s, ms, us or ns). + * ``timestamp``: a preferably non-nullable ``Timestamp(time_unit, "UTC")``, where ``time_unit`` is any Arrow ``TimeUnit`` (s, ms, us or ns). - * ``offset_minutes``: a non-nullable signed 16-bit integer (``Int16``) representing the offset in minutes from the UTC timezone. Negative offsets represent time zones west of UTC, while positive offsets represent east. Offsets range from -779 (-12:59) to +780 (+13:00). + * ``offset_minutes``: a preferably non-nullable signed 16-bit integer (``Int16``) representing the offset in minutes from the UTC timezone. Negative offsets represent time zones west of UTC, while positive offsets represent east. Offsets range from -779 (-12:59) to +780 (+13:00). * Extension type parameters: @@ -571,6 +571,16 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT It is also *permissible* for the ``offset_minutes`` field to be dictionary-encoded with a preferred (*but not required*) index type of ``int8``, or run-end-encoded with a preferred (*but not required*) runs type of ``int8``. +.. note:: + + It is also *permissible* for ``timestamp`` and ``offset_minutes`` to be nullable, even though it is not preferred. + + If ``timestamp`` is nullable and a value is found to be null, then the whole ``TimestampWithOffset`` value should be interpreted as null. One way of achieving this is to drop ``timestamp``'s validity buffer (V1) and replace the top-level struct validity buffer (V2) with the result of ``V1 AND V2``. + + If ``offset`` is nullable and a value is found to be null, then this value should be interpreted as if the offset value were were zero. + + It is *recommended* that implementations normalize this type's representation by dropping the inner validity buffers and applying the aforementioned transformations, only keeping the top-level struct validity buffer. + .. note:: Although not required, it is *recommended* that implementations represent this type as an RFC3339 string when de/serializing to/from JSON, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. From 018b5e8f9326ae403a2e8be7f1e69f25e22dd089 Mon Sep 17 00:00:00 2001 From: serramatutu Date: Thu, 20 Nov 2025 14:34:34 +0100 Subject: [PATCH 09/14] Typos --- docs/source/format/CanonicalExtensions.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index ff1a78efcdc..7f6afbe01b1 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -575,11 +575,11 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT It is also *permissible* for ``timestamp`` and ``offset_minutes`` to be nullable, even though it is not preferred. - If ``timestamp`` is nullable and a value is found to be null, then the whole ``TimestampWithOffset`` value should be interpreted as null. One way of achieving this is to drop ``timestamp``'s validity buffer (V1) and replace the top-level struct validity buffer (V2) with the result of ``V1 AND V2``. + If ``timestamp`` is nullable and a value is found to be null, then the whole ``TimestampWithOffset`` value should be interpreted as null. One way of achieving this is to drop ``timestamp``'s validity buffer (V1) and replace the top-level struct's validity buffer (V2) with the result of ``V1 AND V2``. - If ``offset`` is nullable and a value is found to be null, then this value should be interpreted as if the offset value were were zero. + If ``offset_minutes`` is nullable and a value is found to be null, then this value should be interpreted as if the offset value were were zero. - It is *recommended* that implementations normalize this type's representation by dropping the inner validity buffers and applying the aforementioned transformations, only keeping the top-level struct validity buffer. + It is *recommended* that implementations normalize this type's representation by dropping the inner validity buffers and applying the aforementioned transformations, only keeping the top-level struct's validity buffer. .. note:: From 5c3a3a800db2b14423100e2ec5d46df3af76ae84 Mon Sep 17 00:00:00 2001 From: serramatutu Date: Thu, 20 Nov 2025 15:04:32 +0100 Subject: [PATCH 10/14] Felipe's suggestion --- docs/source/format/CanonicalExtensions.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index 7f6afbe01b1..997ddccd427 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -573,7 +573,7 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT .. note:: - It is also *permissible* for ``timestamp`` and ``offset_minutes`` to be nullable, even though it is not preferred. + It is also *permissible* for ``timestamp`` and ``offset_minutes`` to be nullable, but not recommended. If ``timestamp`` is nullable and a value is found to be null, then the whole ``TimestampWithOffset`` value should be interpreted as null. One way of achieving this is to drop ``timestamp``'s validity buffer (V1) and replace the top-level struct's validity buffer (V2) with the result of ``V1 AND V2``. From d4d50b32e255ce5b1349a75270967fa6168451b3 Mon Sep 17 00:00:00 2001 From: serramatutu Date: Thu, 20 Nov 2025 15:27:28 +0100 Subject: [PATCH 11/14] Make dict and REE section more concise --- docs/source/format/CanonicalExtensions.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index 997ddccd427..d77790d0b0b 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -569,7 +569,7 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT .. note:: - It is also *permissible* for the ``offset_minutes`` field to be dictionary-encoded with a preferred (*but not required*) index type of ``int8``, or run-end-encoded with a preferred (*but not required*) runs type of ``int8``. + It is also *permissible* for the ``offset_minutes`` field to be dictionary-encoded or run-end-encoded. .. note:: From 043b07c9ded4221d3d9e4a7c024c45e0a03b7b7e Mon Sep 17 00:00:00 2001 From: serramatutu Date: Fri, 21 Nov 2025 15:56:52 +0100 Subject: [PATCH 12/14] Implement Pitrou's suggestion - Drop JSON encoding recommendation - Inner fields must be non-nullble - Time unit is not a type parameter --- docs/source/format/CanonicalExtensions.rst | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index d77790d0b0b..4b7feaafbd6 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -555,13 +555,13 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT * The storage type of the extension is a ``Struct`` with 2 fields, in order: - * ``timestamp``: a preferably non-nullable ``Timestamp(time_unit, "UTC")``, where ``time_unit`` is any Arrow ``TimeUnit`` (s, ms, us or ns). + * ``timestamp``: a non-nullable ``Timestamp(time_unit, "UTC")``, where ``time_unit`` is any Arrow ``TimeUnit`` (s, ms, us or ns). - * ``offset_minutes``: a preferably non-nullable signed 16-bit integer (``Int16``) representing the offset in minutes from the UTC timezone. Negative offsets represent time zones west of UTC, while positive offsets represent east. Offsets range from -779 (-12:59) to +780 (+13:00). + * ``offset_minutes``: a non-nullable signed 16-bit integer (``Int16``) representing the offset in minutes from the UTC timezone. Negative offsets represent time zones west of UTC, while positive offsets represent east. Offsets range from -779 (-12:59) to +780 (+13:00). * Extension type parameters: - * ``time_unit``: the time-unit of each of the stored UTC timestamps. + This type does not have any parameters. * Description of the serialization: @@ -571,22 +571,6 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT It is also *permissible* for the ``offset_minutes`` field to be dictionary-encoded or run-end-encoded. -.. note:: - - It is also *permissible* for ``timestamp`` and ``offset_minutes`` to be nullable, but not recommended. - - If ``timestamp`` is nullable and a value is found to be null, then the whole ``TimestampWithOffset`` value should be interpreted as null. One way of achieving this is to drop ``timestamp``'s validity buffer (V1) and replace the top-level struct's validity buffer (V2) with the result of ``V1 AND V2``. - - If ``offset_minutes`` is nullable and a value is found to be null, then this value should be interpreted as if the offset value were were zero. - - It is *recommended* that implementations normalize this type's representation by dropping the inner validity buffers and applying the aforementioned transformations, only keeping the top-level struct's validity buffer. - -.. note:: - - Although not required, it is *recommended* that implementations represent this type as an RFC3339 string when de/serializing to/from JSON, respecting the ``TimeUnit`` precision and time zone offset without loss of information. For example ``2025-01-01T00:00:00Z`` represents January 1st 2025 in UTC with second precision, and ``2025-01-01T00:00:00.000000001-07:00`` represents one nanosecond after January 1st 2025 in UTC-07. - - The rationale behind this recommendation is that many programming languages provide support for parsing RFC3339 out of the box, facilitating consumption of timezone-aware JSON-encoded Arrow arrays without extra boilerplate just for integrating with Arrow. - Community Extension Types ========================= From 7b35e5b676acb28d22241a800cff0b62ffd62a0b Mon Sep 17 00:00:00 2001 From: Lucas Valente Date: Tue, 25 Nov 2025 16:25:02 +0100 Subject: [PATCH 13/14] Formatting Co-authored-by: Joris Van den Bossche --- docs/source/format/CanonicalExtensions.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index 4b7feaafbd6..3795154501e 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -547,7 +547,7 @@ Primitive Type Mappings .. _timestamp_with_offset_extension: Timestamp With Offset -============= +===================== This type represents a timestamp column that stores potentially different timezone offsets per value. The timestamp is stored in UTC alongside the original timezone offset in minutes. This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WITH TIME ZONE``, which is supported by multiple database engines. From c73ec565b4342d219d09b4c4176f47a671d5bd1a Mon Sep 17 00:00:00 2001 From: Lucas Valente Date: Tue, 25 Nov 2025 19:39:21 +0100 Subject: [PATCH 14/14] Reword offsets Co-authored-by: Felipe Oliveira Carvalho --- docs/source/format/CanonicalExtensions.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/format/CanonicalExtensions.rst b/docs/source/format/CanonicalExtensions.rst index 3795154501e..697e7627d89 100644 --- a/docs/source/format/CanonicalExtensions.rst +++ b/docs/source/format/CanonicalExtensions.rst @@ -557,7 +557,7 @@ This extension type is intended to be compatible with ANSI SQL's ``TIMESTAMP WIT * ``timestamp``: a non-nullable ``Timestamp(time_unit, "UTC")``, where ``time_unit`` is any Arrow ``TimeUnit`` (s, ms, us or ns). - * ``offset_minutes``: a non-nullable signed 16-bit integer (``Int16``) representing the offset in minutes from the UTC timezone. Negative offsets represent time zones west of UTC, while positive offsets represent east. Offsets range from -779 (-12:59) to +780 (+13:00). + * ``offset_minutes``: a non-nullable signed 16-bit integer (``Int16``) representing the offset in minutes from the UTC timezone. Negative offsets represent time zones west of UTC, while positive offsets represent east. Offsets normally range from -779 (-12:59) to +780 (+13:00). * Extension type parameters: