[STRAW POLL] (How) should Arrow define storage for "Instant"s

[Weston Pace <we...@gmail.com>]

The discussion in [1] led to the following question.  Before we
proceed on a vote it was decided we should do a straw poll to settle
on an approach (which can then be voted on in a +1/-1 fashion).

---
Some date & time libraries have three temporal concepts.  For the sake
of this document we will call them LocalDateTime, ZonedDateTime, and
Instant.  An Instant is a timestamp that has no meaningful reference
time zone (e.g. events that did not occur on Earth or columns of
timestamps spanning more than one time zone). For more extensive
definitions and a discussion of their semantics and uses see [1].
Currently Arrow describes how to define two of these three concepts
and there is no guideline on how to store an Instant (assuming the
proposal in [2] passes).


This proposal states that Arrow should define how to encode an Instant
into Arrow data.  There are several ways this could happen, some which
change schema.fbs and some which do not.
---

For sample arguments (currently grouped as "for changing schema.fbs"
and "against changing schema.fbs") see [2].  For a detailed definition
of the terms LocalDateTime, ZonedDateTime, and Instant and a
discussion of their semantics see [3].

Options:

A) Do nothing, don’t introduce the nuance of “instants” into Arrow
B) Do nothing, but update the comments in schema.fbs to acknowledge
the existence of the concept and explain that implementations are free
to decide if/how to support the type.
C) Define timestamp with timezone “UTC” as “instant”.
D) Add a first class instant type to schema.fbs
E) Add instant as a canonical extension type

Note: This is just a straw poll and the results will not be binding in
any way but will help craft a future vote.  For example, if the
plurality of votes goes to C but a majority of votes is spread across
A & B then some flavor of A/B would likely be pursued.

Vote for as many options as you would like.

I will summarize and send out the results in 72 hours.

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Weston Pace <we...@gmail.com>]

[1] https://lists.apache.org/thread.html/r8216e5de3efd2935e3907ad9bd20ce07e430952f84de69b36337e5eb%40%3Cdev.arrow.apache.org%3E
[2] https://docs.google.com/document/d/1xEKRhs-GUSMwjMhgmQdnCNMXwZrA10226AcXRoP8g9E/edit?usp=sharing
[3] https://docs.google.com/document/d/1QDwX4ypfNvESc2ywcT1ygaf2Y1R8SmkpifMV7gpJdBI/edit?usp=sharing

On Thu, Jun 24, 2021 at 9:24 AM Weston Pace <we...@gmail.com> wrote:
>
> The discussion in [1] led to the following question.  Before we
> proceed on a vote it was decided we should do a straw poll to settle
> on an approach (which can then be voted on in a +1/-1 fashion).
>
> ---
> Some date & time libraries have three temporal concepts.  For the sake
> of this document we will call them LocalDateTime, ZonedDateTime, and
> Instant.  An Instant is a timestamp that has no meaningful reference
> time zone (e.g. events that did not occur on Earth or columns of
> timestamps spanning more than one time zone). For more extensive
> definitions and a discussion of their semantics and uses see [1].
> Currently Arrow describes how to define two of these three concepts
> and there is no guideline on how to store an Instant (assuming the
> proposal in [2] passes).
>
>
> This proposal states that Arrow should define how to encode an Instant
> into Arrow data.  There are several ways this could happen, some which
> change schema.fbs and some which do not.
> ---
>
> For sample arguments (currently grouped as "for changing schema.fbs"
> and "against changing schema.fbs") see [2].  For a detailed definition
> of the terms LocalDateTime, ZonedDateTime, and Instant and a
> discussion of their semantics see [3].
>
> Options:
>
> A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> B) Do nothing, but update the comments in schema.fbs to acknowledge
> the existence of the concept and explain that implementations are free
> to decide if/how to support the type.
> C) Define timestamp with timezone “UTC” as “instant”.
> D) Add a first class instant type to schema.fbs
> E) Add instant as a canonical extension type
>
> Note: This is just a straw poll and the results will not be binding in
> any way but will help craft a future vote.  For example, if the
> plurality of votes goes to C but a majority of votes is spread across
> A & B then some flavor of A/B would likely be pursued.
>
> Vote for as many options as you would like.
>
> I will summarize and send out the results in 72 hours.

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Weston Pace <we...@gmail.com>]

As of now there are 9 votes for C, 1 for D, and 4 for E (although all
E votes were second-choice votes).  It seems there is consensus around
C.  I apologize for all the noise but to follow the process I'll go
ahead and create one more vote thread to wrap this up.

On Mon, Jun 28, 2021 at 5:44 PM Bryan Cutler <cu...@gmail.com> wrote:
>
> C first choice, E second
>
> On Mon, Jun 28, 2021, 8:40 AM Julian Hyde <jh...@gmail.com> wrote:
>
> > D
> >
> > (2nd choice E if we’re doing ranked-choice voting)
> >
> > Julian
> >
> > > On Jun 24, 2021, at 12:24 PM, Weston Pace <we...@gmail.com> wrote:
> > >
> > > The discussion in [1] led to the following question.  Before we
> > > proceed on a vote it was decided we should do a straw poll to settle
> > > on an approach (which can then be voted on in a +1/-1 fashion).
> > >
> > > ---
> > > Some date & time libraries have three temporal concepts.  For the sake
> > > of this document we will call them LocalDateTime, ZonedDateTime, and
> > > Instant.  An Instant is a timestamp that has no meaningful reference
> > > time zone (e.g. events that did not occur on Earth or columns of
> > > timestamps spanning more than one time zone). For more extensive
> > > definitions and a discussion of their semantics and uses see [1].
> > > Currently Arrow describes how to define two of these three concepts
> > > and there is no guideline on how to store an Instant (assuming the
> > > proposal in [2] passes).
> > >
> > >
> > > This proposal states that Arrow should define how to encode an Instant
> > > into Arrow data.  There are several ways this could happen, some which
> > > change schema.fbs and some which do not.
> > > ---
> > >
> > > For sample arguments (currently grouped as "for changing schema.fbs"
> > > and "against changing schema.fbs") see [2].  For a detailed definition
> > > of the terms LocalDateTime, ZonedDateTime, and Instant and a
> > > discussion of their semantics see [3].
> > >
> > > Options:
> > >
> > > A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> > > B) Do nothing, but update the comments in schema.fbs to acknowledge
> > > the existence of the concept and explain that implementations are free
> > > to decide if/how to support the type.
> > > C) Define timestamp with timezone “UTC” as “instant”.
> > > D) Add a first class instant type to schema.fbs
> > > E) Add instant as a canonical extension type
> > >
> > > Note: This is just a straw poll and the results will not be binding in
> > > any way but will help craft a future vote.  For example, if the
> > > plurality of votes goes to C but a majority of votes is spread across
> > > A & B then some flavor of A/B would likely be pursued.
> > >
> > > Vote for as many options as you would like.
> > >
> > > I will summarize and send out the results in 72 hours.
> >

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Bryan Cutler <cu...@gmail.com>]

C first choice, E second

On Mon, Jun 28, 2021, 8:40 AM Julian Hyde <jh...@gmail.com> wrote:

> D
>
> (2nd choice E if we’re doing ranked-choice voting)
>
> Julian
>
> > On Jun 24, 2021, at 12:24 PM, Weston Pace <we...@gmail.com> wrote:
> >
> > The discussion in [1] led to the following question.  Before we
> > proceed on a vote it was decided we should do a straw poll to settle
> > on an approach (which can then be voted on in a +1/-1 fashion).
> >
> > ---
> > Some date & time libraries have three temporal concepts.  For the sake
> > of this document we will call them LocalDateTime, ZonedDateTime, and
> > Instant.  An Instant is a timestamp that has no meaningful reference
> > time zone (e.g. events that did not occur on Earth or columns of
> > timestamps spanning more than one time zone). For more extensive
> > definitions and a discussion of their semantics and uses see [1].
> > Currently Arrow describes how to define two of these three concepts
> > and there is no guideline on how to store an Instant (assuming the
> > proposal in [2] passes).
> >
> >
> > This proposal states that Arrow should define how to encode an Instant
> > into Arrow data.  There are several ways this could happen, some which
> > change schema.fbs and some which do not.
> > ---
> >
> > For sample arguments (currently grouped as "for changing schema.fbs"
> > and "against changing schema.fbs") see [2].  For a detailed definition
> > of the terms LocalDateTime, ZonedDateTime, and Instant and a
> > discussion of their semantics see [3].
> >
> > Options:
> >
> > A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> > B) Do nothing, but update the comments in schema.fbs to acknowledge
> > the existence of the concept and explain that implementations are free
> > to decide if/how to support the type.
> > C) Define timestamp with timezone “UTC” as “instant”.
> > D) Add a first class instant type to schema.fbs
> > E) Add instant as a canonical extension type
> >
> > Note: This is just a straw poll and the results will not be binding in
> > any way but will help craft a future vote.  For example, if the
> > plurality of votes goes to C but a majority of votes is spread across
> > A & B then some flavor of A/B would likely be pursued.
> >
> > Vote for as many options as you would like.
> >
> > I will summarize and send out the results in 72 hours.
>

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Julian Hyde <jh...@gmail.com>]

D

(2nd choice E if we’re doing ranked-choice voting)

Julian

> On Jun 24, 2021, at 12:24 PM, Weston Pace <we...@gmail.com> wrote:
> 
> The discussion in [1] led to the following question.  Before we
> proceed on a vote it was decided we should do a straw poll to settle
> on an approach (which can then be voted on in a +1/-1 fashion).
> 
> ---
> Some date & time libraries have three temporal concepts.  For the sake
> of this document we will call them LocalDateTime, ZonedDateTime, and
> Instant.  An Instant is a timestamp that has no meaningful reference
> time zone (e.g. events that did not occur on Earth or columns of
> timestamps spanning more than one time zone). For more extensive
> definitions and a discussion of their semantics and uses see [1].
> Currently Arrow describes how to define two of these three concepts
> and there is no guideline on how to store an Instant (assuming the
> proposal in [2] passes).
> 
> 
> This proposal states that Arrow should define how to encode an Instant
> into Arrow data.  There are several ways this could happen, some which
> change schema.fbs and some which do not.
> ---
> 
> For sample arguments (currently grouped as "for changing schema.fbs"
> and "against changing schema.fbs") see [2].  For a detailed definition
> of the terms LocalDateTime, ZonedDateTime, and Instant and a
> discussion of their semantics see [3].
> 
> Options:
> 
> A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> B) Do nothing, but update the comments in schema.fbs to acknowledge
> the existence of the concept and explain that implementations are free
> to decide if/how to support the type.
> C) Define timestamp with timezone “UTC” as “instant”.
> D) Add a first class instant type to schema.fbs
> E) Add instant as a canonical extension type
> 
> Note: This is just a straw poll and the results will not be binding in
> any way but will help craft a future vote.  For example, if the
> plurality of votes goes to C but a majority of votes is spread across
> A & B then some flavor of A/B would likely be pursued.
> 
> Vote for as many options as you would like.
> 
> I will summarize and send out the results in 72 hours.

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Micah Kornfield <em...@gmail.com>]

My preference would be C with the caveat that we replace the word with
"define" as that the  convention for encoding Instant is Timestamp with
timezone "UTC".

My second choice would be E.  (This could either be an extension of option
C, or support any Timestamp with Timezone).

If there are concrete code examples that others can come up with to support
updating Schema.fbs with a new Instant type that aren't addressed by either
of those options, I'd be willing to consider.

Thanks,
Micah

On Thu, Jun 24, 2021 at 12:24 PM Weston Pace <we...@gmail.com> wrote:

> The discussion in [1] led to the following question.  Before we
> proceed on a vote it was decided we should do a straw poll to settle
> on an approach (which can then be voted on in a +1/-1 fashion).
>
> ---
> Some date & time libraries have three temporal concepts.  For the sake
> of this document we will call them LocalDateTime, ZonedDateTime, and
> Instant.  An Instant is a timestamp that has no meaningful reference
> time zone (e.g. events that did not occur on Earth or columns of
> timestamps spanning more than one time zone). For more extensive
> definitions and a discussion of their semantics and uses see [1].
> Currently Arrow describes how to define two of these three concepts
> and there is no guideline on how to store an Instant (assuming the
> proposal in [2] passes).
>
>
> This proposal states that Arrow should define how to encode an Instant
> into Arrow data.  There are several ways this could happen, some which
> change schema.fbs and some which do not.
> ---
>
> For sample arguments (currently grouped as "for changing schema.fbs"
> and "against changing schema.fbs") see [2].  For a detailed definition
> of the terms LocalDateTime, ZonedDateTime, and Instant and a
> discussion of their semantics see [3].
>
> Options:
>
> A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> B) Do nothing, but update the comments in schema.fbs to acknowledge
> the existence of the concept and explain that implementations are free
> to decide if/how to support the type.
> C) Define timestamp with timezone “UTC” as “instant”.
> D) Add a first class instant type to schema.fbs
> E) Add instant as a canonical extension type
>
> Note: This is just a straw poll and the results will not be binding in
> any way but will help craft a future vote.  For example, if the
> plurality of votes goes to C but a majority of votes is spread across
> A & B then some flavor of A/B would likely be pursued.
>
> Vote for as many options as you would like.
>
> I will summarize and send out the results in 72 hours.
>

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Ben Kietzman <be...@ursacomputing.com>]

C

On Thu, Jun 24, 2021, 18:08 David Li <li...@apache.org> wrote:

> I would also be in favor of option C, or also E if having that distinction
> in the schema is important to some application.
>
> -David
>
> On Thu, Jun 24, 2021, at 17:16, Andrew Lamb wrote:
> > C
> >
> > On Thu, Jun 24, 2021 at 5:05 PM Rok Mihevc <ro...@gmail.com> wrote:
> >
> > > C
> > >
> > > On Thu, Jun 24, 2021 at 9:55 PM Nate Bauernfeind <
> > > natebauernfeind@deephaven.io> wrote:
> > >
> > > > Option C.
> > > >
> > > > On Thu, Jun 24, 2021 at 1:53 PM Joris Peeters <
> > > joris.mg.peeters@gmail.com>
> > > > wrote:
> > > >
> > > > > C
> > > > >
> > > > > On Thu, Jun 24, 2021 at 8:39 PM Antoine Pitrou <antoine@python.org
> >
> > > > wrote:
> > > > >
> > > > > >
> > > > > > Option C.
> > > > > >
> > > > > >
> > > > > > Le 24/06/2021 à 21:24, Weston Pace a écrit :
> > > > > > >
> > > > > > > This proposal states that Arrow should define how to encode an
> > > > Instant
> > > > > > > into Arrow data.  There are several ways this could happen,
> some
> > > > which
> > > > > > > change schema.fbs and some which do not.
> > > > > > > ---
> > > > > > >
> > > > > > > For sample arguments (currently grouped as "for changing
> > > schema.fbs"
> > > > > > > and "against changing schema.fbs") see [2].  For a detailed
> > > > definition
> > > > > > > of the terms LocalDateTime, ZonedDateTime, and Instant and a
> > > > > > > discussion of their semantics see [3].
> > > > > > >
> > > > > > > Options:
> > > > > > >
> > > > > > > A) Do nothing, don’t introduce the nuance of “instants” into
> Arrow
> > > > > > > B) Do nothing, but update the comments in schema.fbs to
> acknowledge
> > > > > > > the existence of the concept and explain that implementations
> are
> > > > free
> > > > > > > to decide if/how to support the type.
> > > > > > > C) Define timestamp with timezone “UTC” as “instant”.
> > > > > > > D) Add a first class instant type to schema.fbs
> > > > > > > E) Add instant as a canonical extension type
> > > > > > >
> > > > > > > Note: This is just a straw poll and the results will not be
> binding
> > > > in
> > > > > > > any way but will help craft a future vote.  For example, if the
> > > > > > > plurality of votes goes to C but a majority of votes is spread
> > > across
> > > > > > > A & B then some flavor of A/B would likely be pursued.
> > > > > > >
> > > > > > > Vote for as many options as you would like.
> > > > > > >
> > > > > > > I will summarize and send out the results in 72 hours.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > >
> >
>

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[David Li <li...@apache.org>]

I would also be in favor of option C, or also E if having that distinction in the schema is important to some application.

-David

On Thu, Jun 24, 2021, at 17:16, Andrew Lamb wrote:
> C
> 
> On Thu, Jun 24, 2021 at 5:05 PM Rok Mihevc <ro...@gmail.com> wrote:
> 
> > C
> >
> > On Thu, Jun 24, 2021 at 9:55 PM Nate Bauernfeind <
> > natebauernfeind@deephaven.io> wrote:
> >
> > > Option C.
> > >
> > > On Thu, Jun 24, 2021 at 1:53 PM Joris Peeters <
> > joris.mg.peeters@gmail.com>
> > > wrote:
> > >
> > > > C
> > > >
> > > > On Thu, Jun 24, 2021 at 8:39 PM Antoine Pitrou <an...@python.org>
> > > wrote:
> > > >
> > > > >
> > > > > Option C.
> > > > >
> > > > >
> > > > > Le 24/06/2021 à 21:24, Weston Pace a écrit :
> > > > > >
> > > > > > This proposal states that Arrow should define how to encode an
> > > Instant
> > > > > > into Arrow data.  There are several ways this could happen, some
> > > which
> > > > > > change schema.fbs and some which do not.
> > > > > > ---
> > > > > >
> > > > > > For sample arguments (currently grouped as "for changing
> > schema.fbs"
> > > > > > and "against changing schema.fbs") see [2].  For a detailed
> > > definition
> > > > > > of the terms LocalDateTime, ZonedDateTime, and Instant and a
> > > > > > discussion of their semantics see [3].
> > > > > >
> > > > > > Options:
> > > > > >
> > > > > > A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> > > > > > B) Do nothing, but update the comments in schema.fbs to acknowledge
> > > > > > the existence of the concept and explain that implementations are
> > > free
> > > > > > to decide if/how to support the type.
> > > > > > C) Define timestamp with timezone “UTC” as “instant”.
> > > > > > D) Add a first class instant type to schema.fbs
> > > > > > E) Add instant as a canonical extension type
> > > > > >
> > > > > > Note: This is just a straw poll and the results will not be binding
> > > in
> > > > > > any way but will help craft a future vote.  For example, if the
> > > > > > plurality of votes goes to C but a majority of votes is spread
> > across
> > > > > > A & B then some flavor of A/B would likely be pursued.
> > > > > >
> > > > > > Vote for as many options as you would like.
> > > > > >
> > > > > > I will summarize and send out the results in 72 hours.
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> >
> 

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Andrew Lamb <al...@influxdata.com>]

C

On Thu, Jun 24, 2021 at 5:05 PM Rok Mihevc <ro...@gmail.com> wrote:

> C
>
> On Thu, Jun 24, 2021 at 9:55 PM Nate Bauernfeind <
> natebauernfeind@deephaven.io> wrote:
>
> > Option C.
> >
> > On Thu, Jun 24, 2021 at 1:53 PM Joris Peeters <
> joris.mg.peeters@gmail.com>
> > wrote:
> >
> > > C
> > >
> > > On Thu, Jun 24, 2021 at 8:39 PM Antoine Pitrou <an...@python.org>
> > wrote:
> > >
> > > >
> > > > Option C.
> > > >
> > > >
> > > > Le 24/06/2021 à 21:24, Weston Pace a écrit :
> > > > >
> > > > > This proposal states that Arrow should define how to encode an
> > Instant
> > > > > into Arrow data.  There are several ways this could happen, some
> > which
> > > > > change schema.fbs and some which do not.
> > > > > ---
> > > > >
> > > > > For sample arguments (currently grouped as "for changing
> schema.fbs"
> > > > > and "against changing schema.fbs") see [2].  For a detailed
> > definition
> > > > > of the terms LocalDateTime, ZonedDateTime, and Instant and a
> > > > > discussion of their semantics see [3].
> > > > >
> > > > > Options:
> > > > >
> > > > > A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> > > > > B) Do nothing, but update the comments in schema.fbs to acknowledge
> > > > > the existence of the concept and explain that implementations are
> > free
> > > > > to decide if/how to support the type.
> > > > > C) Define timestamp with timezone “UTC” as “instant”.
> > > > > D) Add a first class instant type to schema.fbs
> > > > > E) Add instant as a canonical extension type
> > > > >
> > > > > Note: This is just a straw poll and the results will not be binding
> > in
> > > > > any way but will help craft a future vote.  For example, if the
> > > > > plurality of votes goes to C but a majority of votes is spread
> across
> > > > > A & B then some flavor of A/B would likely be pursued.
> > > > >
> > > > > Vote for as many options as you would like.
> > > > >
> > > > > I will summarize and send out the results in 72 hours.
> > > > >
> > > >
> > >
> >
> >
> > --
> >
>

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Rok Mihevc <ro...@gmail.com>]

C

On Thu, Jun 24, 2021 at 9:55 PM Nate Bauernfeind <
natebauernfeind@deephaven.io> wrote:

> Option C.
>
> On Thu, Jun 24, 2021 at 1:53 PM Joris Peeters <jo...@gmail.com>
> wrote:
>
> > C
> >
> > On Thu, Jun 24, 2021 at 8:39 PM Antoine Pitrou <an...@python.org>
> wrote:
> >
> > >
> > > Option C.
> > >
> > >
> > > Le 24/06/2021 à 21:24, Weston Pace a écrit :
> > > >
> > > > This proposal states that Arrow should define how to encode an
> Instant
> > > > into Arrow data.  There are several ways this could happen, some
> which
> > > > change schema.fbs and some which do not.
> > > > ---
> > > >
> > > > For sample arguments (currently grouped as "for changing schema.fbs"
> > > > and "against changing schema.fbs") see [2].  For a detailed
> definition
> > > > of the terms LocalDateTime, ZonedDateTime, and Instant and a
> > > > discussion of their semantics see [3].
> > > >
> > > > Options:
> > > >
> > > > A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> > > > B) Do nothing, but update the comments in schema.fbs to acknowledge
> > > > the existence of the concept and explain that implementations are
> free
> > > > to decide if/how to support the type.
> > > > C) Define timestamp with timezone “UTC” as “instant”.
> > > > D) Add a first class instant type to schema.fbs
> > > > E) Add instant as a canonical extension type
> > > >
> > > > Note: This is just a straw poll and the results will not be binding
> in
> > > > any way but will help craft a future vote.  For example, if the
> > > > plurality of votes goes to C but a majority of votes is spread across
> > > > A & B then some flavor of A/B would likely be pursued.
> > > >
> > > > Vote for as many options as you would like.
> > > >
> > > > I will summarize and send out the results in 72 hours.
> > > >
> > >
> >
>
>
> --
>

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Nate Bauernfeind <na...@deephaven.io>]

Option C.

On Thu, Jun 24, 2021 at 1:53 PM Joris Peeters <jo...@gmail.com>
wrote:

> C
>
> On Thu, Jun 24, 2021 at 8:39 PM Antoine Pitrou <an...@python.org> wrote:
>
> >
> > Option C.
> >
> >
> > Le 24/06/2021 à 21:24, Weston Pace a écrit :
> > >
> > > This proposal states that Arrow should define how to encode an Instant
> > > into Arrow data.  There are several ways this could happen, some which
> > > change schema.fbs and some which do not.
> > > ---
> > >
> > > For sample arguments (currently grouped as "for changing schema.fbs"
> > > and "against changing schema.fbs") see [2].  For a detailed definition
> > > of the terms LocalDateTime, ZonedDateTime, and Instant and a
> > > discussion of their semantics see [3].
> > >
> > > Options:
> > >
> > > A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> > > B) Do nothing, but update the comments in schema.fbs to acknowledge
> > > the existence of the concept and explain that implementations are free
> > > to decide if/how to support the type.
> > > C) Define timestamp with timezone “UTC” as “instant”.
> > > D) Add a first class instant type to schema.fbs
> > > E) Add instant as a canonical extension type
> > >
> > > Note: This is just a straw poll and the results will not be binding in
> > > any way but will help craft a future vote.  For example, if the
> > > plurality of votes goes to C but a majority of votes is spread across
> > > A & B then some flavor of A/B would likely be pursued.
> > >
> > > Vote for as many options as you would like.
> > >
> > > I will summarize and send out the results in 72 hours.
> > >
> >
>


--

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Joris Peeters <jo...@gmail.com>]

C

On Thu, Jun 24, 2021 at 8:39 PM Antoine Pitrou <an...@python.org> wrote:

>
> Option C.
>
>
> Le 24/06/2021 à 21:24, Weston Pace a écrit :
> >
> > This proposal states that Arrow should define how to encode an Instant
> > into Arrow data.  There are several ways this could happen, some which
> > change schema.fbs and some which do not.
> > ---
> >
> > For sample arguments (currently grouped as "for changing schema.fbs"
> > and "against changing schema.fbs") see [2].  For a detailed definition
> > of the terms LocalDateTime, ZonedDateTime, and Instant and a
> > discussion of their semantics see [3].
> >
> > Options:
> >
> > A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> > B) Do nothing, but update the comments in schema.fbs to acknowledge
> > the existence of the concept and explain that implementations are free
> > to decide if/how to support the type.
> > C) Define timestamp with timezone “UTC” as “instant”.
> > D) Add a first class instant type to schema.fbs
> > E) Add instant as a canonical extension type
> >
> > Note: This is just a straw poll and the results will not be binding in
> > any way but will help craft a future vote.  For example, if the
> > plurality of votes goes to C but a majority of votes is spread across
> > A & B then some flavor of A/B would likely be pursued.
> >
> > Vote for as many options as you would like.
> >
> > I will summarize and send out the results in 72 hours.
> >
>

Re: [STRAW POLL] (How) should Arrow define storage for "Instant"s

[Antoine Pitrou <an...@python.org>]

Option C.


Le 24/06/2021 à 21:24, Weston Pace a écrit :
> 
> This proposal states that Arrow should define how to encode an Instant
> into Arrow data.  There are several ways this could happen, some which
> change schema.fbs and some which do not.
> ---
> 
> For sample arguments (currently grouped as "for changing schema.fbs"
> and "against changing schema.fbs") see [2].  For a detailed definition
> of the terms LocalDateTime, ZonedDateTime, and Instant and a
> discussion of their semantics see [3].
> 
> Options:
> 
> A) Do nothing, don’t introduce the nuance of “instants” into Arrow
> B) Do nothing, but update the comments in schema.fbs to acknowledge
> the existence of the concept and explain that implementations are free
> to decide if/how to support the type.
> C) Define timestamp with timezone “UTC” as “instant”.
> D) Add a first class instant type to schema.fbs
> E) Add instant as a canonical extension type
> 
> Note: This is just a straw poll and the results will not be binding in
> any way but will help craft a future vote.  For example, if the
> plurality of votes goes to C but a majority of votes is spread across
> A & B then some flavor of A/B would likely be pursued.
> 
> Vote for as many options as you would like.
> 
> I will summarize and send out the results in 72 hours.
>