OK -- Micah -- I think it's fine to change from DurationInterval -> Duration if no one else chimes in here by tomorrow or so
On Sun, May 5, 2019 at 5:02 AM Jacques Nadeau <jacq...@apache.org> wrote: > > yeah, I think Duration is better than DurationInterval > > On Sat, May 4, 2019 at 3:35 AM Wes McKinney <wesmck...@gmail.com> wrote: > > > I've just reviewed the format and C++ changes in > > https://github.com/apache/arrow/pull/3644 which look good to me modulo > > minor comments. > > > > Can someone take a look at the Java changes soon so we move this > > toward completion? > > > > One question came up of whether "DurationInterval" is the name we > > want. It might be more clear to call it simply "Duration" > > > > On Tue, Apr 30, 2019 at 6:57 PM Micah Kornfield <emkornfi...@gmail.com> > > wrote: > > > > > > Sorry for the type OK, I think https://github.com/apache/arrow/pull/3644 > > is > > > now ready to review. > > > > > > On Tue, Apr 30, 2019 at 4:56 PM Micah Kornfield <emkornfi...@gmail.com> > > > wrote: > > > > > > > OK, I think https://github.com/apache/arrow/pull/3644 is no ready to > > > > review. > > > > > > > > It includes Java implementation of DurationInterval and C++ > > > > implementations of DurationInterval and the original interval types. I > > > > added documentation to Schema.fbs regarding the original interval types > > > > (TL;DR; YEAR_MONTH is expected to be supported by all implementations > > > > DAY_TIME is not, which I believe as based on previous ML > > conversations). > > > > Please let me know if there are issues with this language and I can > > remove > > > > it. > > > > > > > > > > > > On Monday, April 8, 2019, Krisztián Szűcs <szucs.kriszt...@gmail.com> > > > > wrote: > > > > > > > >> The vote carries with 4 binding +1 votes. > > > >> > > > >> Micah, what are the next steps? > > > >> Are You going to finalize the PR? > > > >> > > > >> On Sun, Apr 7, 2019 at 11:13 AM Uwe L. Korn <uw...@xhochy.com> wrote: > > > >> > > > >> > +1 (binding) > > > >> > > > > >> > On Sat, Apr 6, 2019, at 2:44 AM, Kouhei Sutou wrote: > > > >> > > +1 (binding) > > > >> > > > > > >> > > In <CAKa9qDm+aO-9q_6x3XCXCJ5wOuqZb3spuLtGOY4mi3v5AB= > > > >> p...@mail.gmail.com> > > > >> > > "[VOTE] Add new DurationInterval Type to Arrow Format" on Wed, > > 3 Apr > > > >> > > 2019 07:59:56 -0700, > > > >> > > Jacques Nadeau <jacq...@apache.org> wrote: > > > >> > > > > > >> > > > I'd like to propose a change to the Arrow format to support a > > new > > > >> > duration > > > >> > > > type. Details below. Threads on mailing list around discussion. > > > >> > > > > > > >> > > > > > > >> > > > // An absolute length of time unrelated to any calendar > > artifacts. > > > >> > For the > > > >> > > > purposes > > > >> > > > /// of Arrow Implementations, adding this value to a Timestamp > > > >> ("t1") > > > >> > > > naively (i.e. simply summing > > > >> > > > /// the two number) is acceptable even though in some cases the > > > >> > resulting > > > >> > > > Timestamp (t2) would > > > >> > > > /// not account for leap-seconds during the elapsed time between > > > >> "t1" > > > >> > and > > > >> > > > "t2". Similarly, representing > > > >> > > > /// the difference between two Unix timestamp is acceptable, but > > > >> would > > > >> > > > yield a value that is possibly a few seconds > > > >> > > > /// off from the true elapsed time. > > > >> > > > /// > > > >> > > > /// The resolution defaults to > > > >> > > > /// millisecond, but can be any of the other supported TimeUnit > > > >> values > > > >> > as > > > >> > > > /// with Timestamp and Time types. This type is always > > represented > > > >> as > > > >> > > > /// an 8-byte integer. > > > >> > > > table DurationInterval { > > > >> > > > unit: TimeUnit = MILLISECOND; > > > >> > > > } > > > >> > > > > > > >> > > > > > > >> > > > Please vote whether to accept the changes. The vote will be open > > > >> > > > for at least 72 hours. > > > >> > > > > > > >> > > > [ ] +1 Accept these changes to the Flight protocol > > > >> > > > [ ] +0 > > > >> > > > [ ] -1 Do not accept the changes because... > > > >> > > > > > >> > > > > >> > > > > > >
