I would like to propose a vote on this feature this week. Could someone from the Java side weigh in since there is some existing code relating to intervals there already?
On Wed, Mar 27, 2019 at 10:49 PM Micah Kornfield <emkornfi...@gmail.com> wrote: > > Hi Wes, > Thanks for the feedback. I'm happy to update the PR to include c++ and > python once there is consensus on the format change. I'd also welcome > feedback and an extra set of eyes on the issues I raised below, since it is > hard to change once we make a release. > > Based on previous discussions, I thought we were OK supporting YEAR_MONTH and > deprecating or making DAY_TIME optional. I'm also happy to try to add > support for these in C++/Python as a separate PR. > > I'm not sure what the "Apache Way" is on this, but it seems like this > particular issue has taken a long time to resolve, because these threads tend > to lose steam (even this thread only had your response over the course of a > week). The only guidance I can find is Lazy Consensus [1], but maybe that > doesn't apply in this situation? > > In short, it would be nice to get explicit consensus via a PMC vote or an > alternative proposal made, that can gain consensus. I'm happy to help out in > either case, but would like avoid this stalling out yet again. > > Thanks, > Micah > > [1] https://community.apache.org/committers/lazyConsensus.html > > On Wednesday, March 27, 2019, Wes McKinney <wesmck...@gmail.com> wrote: >> >> hi Micah, >> >> Sorry for the delay. >> >> I'm in favor of introducing the Duration/DurationInterval type to >> unblock the difference-of-timestamps / timedelta use case that many >> Arrow users have. I'd like Jacques or someone from the Java side to >> comment about this before starting a vote. >> >> We can merge these changes into a feature branch and I or someone else >> can complete the C++ side and work on integration tests (so we >> eventually have proof of two complete implementations) >> >> I'm not sure what to do with the existing YEAR_MONTH and DAY_TIME >> interval types. These are featured in a number of SQL database systems >> and so one option is to simply leave them as is. >> >> Thanks >> Wes >> >> On Sat, Mar 23, 2019 at 12:58 AM Micah Kornfield <emkornfi...@gmail.com> >> wrote: >> > >> > Hi arrow-dev, >> > I just wanted to bump this thread to see if anyone wanted to comment or >> > discuss a path forward. >> > >> > If no one chimes in by Monday evening, could I ask a PMC member to start a >> > vote on Tuesday (I believe a member of the PMC needs to initiate a vote?) >> > >> > I will implement the C++ side once there is consensus around the change to >> > the format. >> > >> > Thanks, >> > Micah >> > >> > On Tue, Mar 19, 2019 at 12:13 AM Micah Kornfield <emkornfi...@gmail.com> >> > wrote: >> > >> > > Hi Arrow Dev, >> > > Based on the recent thread on discussing and voting on changes to files >> > > under format, I'd figure I'd try see how the process works for changes to >> > > Schema.fbs to close out lingering time interval issues. In particular, >> > > ARROW-352 (Interval(DAY_TIME) has no unit) and ARROW-835 (Add Timedelta >> > > type to describe time intervals). >> > > >> > > I submitted a PR [1] that introduces a new DurationType that models >> > > (sub)seconds (excluding leap seconds) as a 8-byte integer type. Some of >> > > these issues have been discussed previously, the most recent thread was >> > > within the last month [2]. >> > > >> > > The reason for creating a new type is to avoid breaking changes with >> > > existing types (in particular Interval[DAY_TIME] in Java). I think >> > > things worth discussing are: >> > > >> > > 1. Is this a desirable change in principle? >> > > 2. Naming: is DurationInterval a good name (should it be TimeDelta)? >> > > 3. New Type: Should this be collapsed as a new enum on Interval (because >> > > it excludes leap-seconds, I think it still technically falls into the >> > > class >> > > of Calendar like objects). >> > > >> > > Please feel free to add items for discussion. >> > > >> > > I'm not sure the typical time that discussions are held open for, but it >> > > would be great if we could try to get to a consensus sometime soon (and >> > > then schedule a vote). Maybe early next week is a good goal to aim for? >> > > >> > > Thanks, >> > > Micah >> > > >> > > >> > > [1] https://github.com/apache/arrow/pull/3644 >> > > [2] >> > > https://lists.apache.org/thread.html/0e606a6afd2332b4ae5b4382e533bea309c790ea71c05047cf983372@%3Cdev.arrow.apache.org%3E >> > >
