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