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.
