> > Any SQL interface to Arrow should follow the SQL standard. So, for > instance, if a column has TIMESTAMP type, it should behave as a > date-time without a time-zone.
At least in bigquery we do the following mapping: SQL TIMESTAMP -> Arrow Timestamp with "UTC" timezone SQL DATETIME -> Arrow Timestamp without a time-zone. On Wed, Jun 2, 2021 at 12:39 PM Julian Hyde <jh...@apache.org> wrote: > Good time libraries support all. E.g. Jodatime [1] has > > * Instant - an instantaneous point on the time-line > * DateTime - full date and time with time-zone > * LocalDateTime - date-time without a time-zone > > The SQL world isn't quite as much of a mess as Adam makes it out to > be. The SQL standard defines TIMESTAMP, DATE and TIME as zoneless > (like Joda's LocalDateTime) and most DBs have types that behave in > that way. Often those DBs also have types that behave like Instant and > DateTime (but naming is a little inconsistent). > > I recommend that Arrow supports all three. Choose clear, distinct > names for all three, consistent with names used elsewhere in the > industry. > > Any SQL interface to Arrow should follow the SQL standard. So, for > instance, if a column has TIMESTAMP type, it should behave as a > date-time without a time-zone. > > Julian > > [1] https://www.joda.org/joda-time/ > > On Wed, Jun 2, 2021 at 10:43 AM Rok Mihevc <rok.mih...@gmail.com> wrote: > > > > On Wed, Jun 2, 2021 at 3:23 PM Joris Peeters <joris.mg.peet...@gmail.com > > > > wrote: > > > > > You could store epoch offsets, but interpret them in the local > timezone. > > > E.g. (0, "America/New_York") could mean 1970-01-01 00:00:00 in the New > York > > > timezone. > > > At least one nasty problem with that is ambiguous times, i.e. when the > > > clock turns back on going from DST to ST, as well as invalid times > (when > > > the clock moves forwards, meaning some epoch offsets never occur). > > > > > > > Another problem is calendars change (see Adam's points) so the offset > would > > not be constant. >
