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... >> > > >> > >> >
